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Chapter  I 

DITRODUGTION 

I. A.   Opening  Remarks 

The  title  of  this  dissertation  is  descriptive;   it  is  about 
"Aggregate  Production  Scheduling*  by  Linear  Programming**  with  Vari- 
able Planning  Interval."  Its  purpose,  however,  is  neither  to  expound 
nor  to  expand  the  theory  of  LP.  Similarly,  it  represents  no  significant 
contribution  to  the  theory  of  APS.   Instead,  it  represents,  I  hope,  a 
contribution  to  the  literature  of  the  practice  of  both  arts.   It  ex- 
plores a  stiuation  where  LP  was  a  potentially  powerful  technique  for 
APS,  but  where  organizational  and  environmental  factors  dictated  a 
system  combining  LP's  virtues  with  ease  of  use  and  very  quick  response. 
It  deals  largely  with  the  steps  taken  to  make  an  LP-based  production 
planning  system  viable  under  these  difficult  but  commonly-encountered 
conditions.  The  resulting  system  was  a  rather  complex  one,  consisting 
of  many  stages,  both  manual  and  mechanical.   The  final  system  repre- 
sents a  proposed  (indeed,  implemented)  solution  to  a  problem  which  can 
be  viewed  as  falling  on  at  least  three  levels. 

At  the  highest  (or  most  abstract)  level,  the  question  is  one  of 
the  application  of  static  models  to  dynamic  situations.   Analytically, 
this  is  done  all  the  time.   One  need  only  ] ook  at  the  literature  of 


*Hereafter,  APS. 


**Hereafter,  LP. 


Electrical  Engineering,  where  "quasi-static"  models  are  in  cooimon  use, 
primarily  because  they  work,  but  also  because  truly  dynamic  models 
are  clumsy  and  nearly  uncomputable  in  many  real  situations.*  The 
essence  of  "quasi-static"  analysis  is  the  assumption  that  the  effects 
of  time-rate-of-change  are  small  enough  so  that,  for  all  practical  pur- 
poses, a  given  system's  behavior  over  time  may  be  viewed  as  a  series 
of  snapshots,  each  of  which  represents  the  state  of  the  system  at  a 
particular  instant  in  time.   If  the  instants  are  chosen  closely  enough, 
then  a  projection  of  the  state  of  the  system  at  instant  N  +  1  is 
approximated  by  its  state  at  N  plus  no  more  than  first-order  effects. 
Useful  results  are  regularly  obtained  from  such  analysis. 

At  the  second  or  middle  level,  we  are  discussing  a  model-based 
management  information  system  whose  underlying  model  is  basically 
static  but  whose  regular  employment  is  in  a  highly  dynamic  environment. 
In  this  sense,  the  work  will  have  meaning  for  anyone  who  has  a  well- 
defined  problem  and  a  well-defined  technique  for  solution,  where  the 
mismatch  between  problem  and  solution  comes  about  because  the  model 
underlying  the  technique  assumes  its  inputs  constant.   For  example, 
an  LP  model,  unless  deliberately  formulated  as  a  multi-period  model, 
assumes  constant  prices  over  the  (single)  period  involved. 

We  assert  that  the  vast  majority  of  (normative)  management  models 
are  static  in  nature  and  that  they  are  regularly  employed  in  dynamic 
dituations.   The  process  of  matching  model  to  environment  is  not, 


♦See,  for  example,  Adler,  et  al.  (1'+), 


however,  always  straightforward.  We  claim  that  this  particular  case 
discusses  a  model  which  is  especially  complex  in  a  "world"  perceived 
by  its  "citizens"  as  especially  dynamic. 

The  "ideal"  system  of  Chapter  II  essentially  represents  a  struc- 
ture, drawing  heavily  on  current  computer  technology,  for  providing 
an  interface  between  such  a  static  model  (in  this  case  an  optimiza- 
tion model)  and  a  real  world  in  which  hard  decisions  must  be  made  in 
the  face  of,  not  uncertainty  in  the  usual  sense,  but  rather  instability 
of  the  criteria  by  which  performance  is  ultimately  judged,  in  this 
case  that  weighted  sum  of  prices  called  "profits." 

At  the  third  or  lowest  level,  we  are  attacking  the  problem  of 
implementing  a  very  complex  system  whose  natural  home  is  a  large, 
random-access,  computer  system  in  a  relatively  small,  cash-short  com- 
pany having  limited  computer  capability.   The  problem  of  matching 
an  ambitious  system  to  an  (objectively)  inadequate  information-process- 
ing facility  provides  the  theme  of  Chapter  III.   Inevitably,  this  re- 
cital includes  some  purely  parochial  details,  but  we  still  expect  these 
sections  to  be  of  value  to  anyone  faced  with  a  similar  problem.   We 
may  say,  in  fact,  that  the  third  level  of  this  work  is  the  attempt 
to  bring  some  basic  management  science  techniques  to  bear  on  the  prob- 
lems of  a  real  company  which,  without  such  an  unusual  effort,  could 
not  have  expected  to  benefit  therefrom.  While  the  attempt  was  not 
wholly  successful,  many  lessons  were  learned,  most  of  which  are  in- 
cluded. 

The  remainder  of  this  work  assumes  a  working  knowledge  of  LP. 


The  reader  unfamiliar  with  the  technique  and  its  terminology  is 
referred  to  the  references  cited  in  I.D.  A  brief  summary  is  in- 
cluded in  the  appendix  to  Chapter  III. 


1.3.   Plan  of  the  Work 

The  organization  of  this  paper  is  opposite  to  that  of  most  similar 
works.   Rather  than  a  theoretical  development  followed  by  one  or  more 
case  studies,  this  paper  is  driven  by  one  particular  case  study,  and 
theoretical  development  is  interspersed  as  required.   This  follows  the 
actual  course  of  the  project  in  that  it  was  the  existence  of  this  par- 
ticular problem  which  prompted  the  theoretical  development.   The  whole 
will  be  seen  to  resemble  a  narrative  of  the  "Had  I  But  Knownl"  school. 

The  remainder  of  this  chapter  presents  a  very  brief  description  of 
the  problem  attacked  and  a  discussion  of  previous  work  which  bears  on 
it. 

Chapter  II  describes  the  problem  in  more  detail,  defines  some  terms, 
discusses  a  number  of  theoretical  approaches,  offers  an  idealized  solu- 
tion to  the  problem,  and  states  what  must  be  regarded  as  this  work's 
hypothesis:   that  a  production  planning  system  based  on  severely  limited 
man-machine  interaction  can  give  performance  closely  approximating  that 
of  an  "ideal"  system. 

Chapter  III  describes  the  design,  construction,  and  implementation 
of  the  LP  model  and  its  support  system,  which  together  constitute  the 
core  of  a  production  planning  system  for  Peerless.   An  appendix  to 
Chapter  III  describes  the  model  and  its  support  system  as  of  December, 
1967.   Those  interested  in  implementing  similar  systems  may  profit  by 
reading  the  appendix  to  Chapter  III  before  reading  Chapter  III  itself. 
Others  will  wish  to  omit  it  entirely. 

Chapter  IV  discusses  conclusions  and  implications  of  this  worK 
for  Peerless  in  particular  and  management  in  general. 


I.e.   Brief  Statement  of  the  Problem 

The  problem  was  to  design  a  system  to  aid  the  Peerless  Provisioners  in 
their  function,  which  is  to  serve  as  an  interface  between  the  Kill-and- 
cut-out  (abbatoir)  and  production/sales  function.   The  provisioners  have 
effective  (if  not  always  official)  control  over  about  1000  separate, 
more-or-less  manipulable  quantities,  the  vast  majority  of  which  repre- 
sent allocations  of  various  raw  materials  to  different  production  pro- 
cesses.  This  is  a  complex  and  highly  demanding  job  at  best.   It  is 
greatly  complicated  by  the  facts  that  prices  for  raw  materials  change 
quite  rapidly  sometimes,  and,  while  prices  for  finished  goods  are 
thought  to  be  relatively  stable,  the  demand  for  finished  goods  can  be 
greatly  upset  by  a  surprise  order  and/or  cancellation  by  a  large  chain. 

The  requirement,  then,  was  for  a  production/provisioning  planning 
system  which  would  be : 

a)  Prescriptive  —  to  give  recommended  values  of  tne  1000  levels, 
thus  reducing  the  provisioners'  task  to  one  of  review  and 
reconciliation,  rather  than  creation  of  all  1000. 

b)  Consistent  —  to  assure  feasibility  of  the  plan. 

c)  Global  —  to  account  for  the  interaction  of  each  decision  on 
all  others. 

d)  Economic  —  to  wring  every  penny  from  temporary  market  imper- 
fections. 

Since  LP  is,  by  its  nature,  economic,  prescriptive,  and  consistent; 
and,  since  it  is  as  global  as  you  want  it  to  be,  LP  seemed  a  good  base 
for  such  a  planning  system.   However,  it  was  also  required  that  the  sys- 
tem be: 


e)  Usable  by  present  personnel  —  to  make  use  of  many  highly 
competent  (and  not  very  quantitatively-oriented)  employees. 

f)  Quick  to  respond  to  rapid  changes  in  the  environment  —  to 
take  full  advantage  of  "breaks"  offered  by  the  market  and  to 
avoid  disastrous  behavior  in  the  face  of  price  and  quantity 
changes. 

Chapter  II  describes  the  provisioning  environment  in  considerably 
more  detail. 


I.D.   Brief  Survey  of  Relevant  Literature 

The  problem  attacked  in  this  paper  is  one  of  aggregate  production 
scheduling.   Three  references  dealing  extensively  with  this  area  are 
Bowman  and  Fetter  (1).  Holt,  et  al.  (2),  and  Buff a  (l6). 

The  specific  technique  on  which  the  planning  system  is  based  is 
Linear  Programming.   For  descriptions  of  the  history,  methods,  and  ap- 
plications of  LP,  see  Hadley  (3)  and/or  Vajda  (4).  We  have  adopted 
Hadley's  terminology  in  the  main. 

Much  attention  is  given  in  this  paper  to  questions  of  how  often 
to  re-plan.   Insofar  as  this  question  can  be  related  to  delays  affect- 
ing the  flow  of  planning  and  control  information,  the  work  of  Forrester 
(5)  will  be  relevant.   For  a  very  specific  attempt  at  evaluating  the 
costs  of  such  information  delays,  see  Boyd  and  Krasnow  (6).   Some  no- 
tion of  the  interactions  between  frequency,  recency,  and  amount  of  in- 
formation as  used  for  control  purposes  can  be  had  from  the  literature 
of  quality  control.   See  Duncan  (7),  especially  the  sections  on  fre- 
quency of  sampling  for  variables  control  charts. 

Two  very  useful  references  on  planning  and  control  are  Emery  (8) 
and  Carroll  (9).   Emery  includes  a  framework  for  analysis  of  the  cost 
and  value  of  information  as  related  to  recency,  accuracy,  and  the  liKe. 
Carroll  provides  a  useful  set  of  dimensions  along  which  an  operational 
control  system  can  be  measured,  and  also  defines  a  set  of  categories 
into  which  such  control  systems  can  be  classified.  We  use  three  of 
his  definitions  extensively: 

Local-real-time,  in  which  decision-making  takes  place  as 


by  the  process  being  controlled,  based  on  a  local  data  base; 

Global-periodic ,  in  which  decision-making  takes  place  rela- 
tively infrequently  based  on  a  system-wide  data  base;  and 

On-line-real-time,  in  which  decision-making  is  continuous, 
based  on  immediate  access  to  a  system-wide  data  base. 

Considerable  work  exists  on  LP  in  a  meat-packing  environment. 
See,  for  example:   Snyder  (10);  Armbruster  and  Snyder  (11);  Snyder  and 
French  (12);  and  Swackhamer  and  Snyder  (13)-  The  last  is  especially 
interesting,  since  it  describes  an  integrated  planning  and  control 
system  based  on  an  LP  model  and  comprising,  in  addition,  a  forecasting 
subsystem  and  a  report  generation  subsystem.   The  chief  differences 
between  the  system  described  herein  and  that  described  by  Swackhamer 
and  Snyder  are  that  the  latter: 

1)  is  based  on  an  LP  model  of  a  very  much  smaller  subset  of 
meat-packing  operations,  specifically  the  production  of 
sausage  and  luncheon  meat  products; 

2)  is  not  concerned  directly  with  planning  interval  or, 
apparently,  with  rapidly  changing  prices; 

3)  takes  explicit  account  of  cash  limitations;  and 

4)  provides  much  more  comprehensive  output  for  marketing 
operations. 
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Chapter  II 
THS  PROBLEM  AND  ITS  SOLUTION 

II. A.   Issues  Raised  by  the  Use  of  LP  at  Peerless 

The  aggregate  production  scheduling  problem  may  be  conveniently 
thought  of  as  the  problem  of  determining  the  levels  of  production  effort, 
resource  use,  and  asset  growth  (or  decline)  which  best  satisfy  some  set 
of  goals.   Various  mathematical  optimization  or  programming  techniques 
have  proven  themselves  useful  for  this  task,  especially  in  those  cases 
where  the  goals  are  expressible  in  terms  of  simple  profitability  or 
another  easily  quantifiable  measure.   Snyder*  has  shown  the  applica- 
bility of  LP  to  meat-packing,  but  we  must  somehow  cope  with  the  fact 
that,  for  Peerless'  purposes: 

1.  An  appropriately-complex  LP  model  is  large,  unwieldy  .  and 
expensive  to  maintain,  run,  and  interpret; 

2.  The  price  and  requirement  vectors  are  alleged  to  change 
rapidly  with  respect  to  the  normal  decision-period; 

3-   The  structural  equations  of  the  model  change  slowly  but  signi- 
ficantly over  time,  with  regular  seasonal  variations,  evolu- 
tionary changes  in  manufacturing  methods,  and  the  occasional 
major  change  reflecting  technological  improvement  or  similar 
exogenous  influence;  and 

4,   The  individuals  charged  with  the  provisioning/production  sched- 
uling function  have  been  chosen  for  their  proven  intuition  and 
management  ability,  rather  than  for  their  understanding  of  LP 


*See  (10,11.12,13). 
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in  particular  or  quantitive  methods  in  general. 
Clearly,  intelligent  use  of  LP  in  such  a  situation  will  require  the  an- 
swering of  many  questions,  but  three  of  the  more  interesting  and  itutnedi- 
ate  are: 

1)  At  what  level  of  aggregation  should  the  model  be  constructed; 
and  what  does  "appropriately  complex"  mean?  An  overly  aggregated  model 
may  mean  passing  up  significant  profit  opportunities,  but,  on  the  other 
hand,  a  really  detailed  model  will  be  expensive  to  run,  will  obviously 
require  more  turn-around  time  (important  in  a  fast-breaking  world),  may 
lead  to  "driving"  management  over  very  unimportant  details,  and  may  be 
more  confusing  than  helpful. 

2)  What  subset  of  the  output  available  from  LP  do  we  present  to 
management,  and  how  do  we  present  it?  This  question  also  has  its  eco- 
nomic side,  since  there  are  some  incremental  costs  associated  with  gain- 
ing any  information  from  an  LP  run,  beyond  simple  levels  of  activity. 

3)  How  often  should  the  model  be  run  and  how  often  should  the  out- 
put be  presented  to  the  users?  Again,  while  there  are  obvious  advan- 
tages to  frequent  runs,  the  cost  may  be  high,  not  only  for  the  runs 
themselves,  but  also  for  changing  the  levels  of  activity  in  respnse  to 
new  runs,  and  for  management  time  required  to  digest  each  new  set. 

While  the  third  question  is  of  major  interest,  there  is  extremely 
close  interaction  among  the  three,  and  we  really  are  forced  to  consider 
them  together.  We  are  thus  going  to  have  to  answer  the  single  question: 
How  can  one  make  good  use  of  LP  in  such  an  environment?  This,  of  corse, 
is  where  we  started. 

In  demonstrating  that  LP  would  be  a  useful  tool  for  procurement, 
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provisioning,  and  production  at  Peerless  (PPPP,  henceforth),  we  immediately 
fetch  up  against  some  obstacles.   The  literature  abounds  with  examples 
of  successful  use  of  LP  in  other  industrial  situations  which  are  super- 
ficially similar,  but  there  is  general  agreement  in  the  industry  that 
meat  packing  is  different.*  There  is  also  some  work  on  L,P  in  meat 
packing,  mostly  having  to  do  with  sausage  formulation.   Snyder  has  writ- 
ten several  papers  on  the  subject  and  has  considered  the  integrated  prob- 
lem, but  he  has  reported  only  very  small  models  (around  100  variables). 
In  short,  the  published  literature  is  of  little  use  in  giving  clues  as 
to  the  applicability  of  the  technique  at  realistic  levels  of  aggregation. 

However,  the  following  considerations  seem  to  argue  persuasively 
for  LP  for  PPPP: 

1.  Peerless  processes  physical  material  into  other  physical  ma- 
terial; this  fact,  coupled  with  some  elementary  mechanics, 
suggests  that  we  can  assume  constant  returns  to  scale  and 
linear  structural  equations. 

2.  Peerless  is  a  price-taker,  indicating  a  linear  marginal  profit 
function. 

3.  LP  would  provide,  in  this  context,  a  scheduling  tool  utilizing 
rational  economic  criteria  ar.d  global  data. 

^.   Building  and  running  such  a  model  is  feasible. 

5.   By-product  information  would  be  of  great  help  at  each  decision- 
making point  (for  example,  the  reduced  costs  and  shadow  prices 
would  give  the  hog-buyer  confidence  in  the  range  of  prices  which 


*  " 


The  soft  underbelly  of  American  industry 
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he  could  offer  and  still  be  profitable). 
There  are  other  reasons  why  LP  would  appear  to  make  a  good  basis 
for  PPPP,  but  most  reduce  to  one  of  those  mentioned  above.   There  are 
arguments  against  LP  as  well: 

1.  Designing  and  building  such  a  model  is  expensive. 

2.  Running  it  is  expensive. 

3.  Because  prices  may  change  rapidly,  information  is  often 
needed  rapidly  if  it  is  not  to  be  obsolete. 

^.   Peerless  has  neither  the  machines  nor  the  people  to  support 
the  maintenance  and  running  of  a  large,  complicated  system 
of  any  kind. 

5.  A  relatively  small  error  in  data  input  could  produce  a 
profound  schedule  error  causing  large  losses. 

With  respect  to  (4)  above,  large  machines  are  available  from  serv- 
ice bureaus  on  reasonable  (if  sometimes  mysterious)  terms.  With  respect 
to  (1),  (2),  and  the  people  part  of  (4),  one  must  resort  to  the  well- 
known  relationship  between  eggs  and  omelets;  corporate  survival  comes 
high,  and  cost  arguments  bear  as  heavily  on  other  methods  of  meeting 
the  PPPP  problem  as  they  do  on  LP.   We  have  already  stated  (3);  (5) 
remains  in  full  force. 

We  are  now  in  a  position  to  state  the  outlines  of  an  integrated 
PPPP  system  based  on  LP.   Thus: 

A  PPPP  system  must  make  use  of  global  economic  criteria 

to  produce  recommended  aggregate  production  schedules.   It 

must  guide  the  management  and  not  drive  it;  that  is,  it  must 
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-nust  permit  of  remote  operation  until  Peerless  acquires  large  com- 
puting capability.   It  must  present  an  amount  of  information 
which  is  neither  too  compact  nor  too  voluminous,  and  the  informa- 
tion must  be  presented  in  a  form  meaningful  to  management.   A 
PPPP  system  must  be  able  to  detect  certain  data  errors  to  pre- 
vent bad  schedules,  and  it  must  either  be  able  to  respond 
quickly  to  changes  in  the  market,  or  else  have  features  which 
permit  its  output  to  be  useful  during  the  period  required  for 
response. 
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11.3.   Procurement.  Provisioning,  and  Production  at  Peerless 

It  now  becomes  necessary  to  describe  the  actual  environment 
studied,  in  order  to  bring  some  of  the  issues  into  sharper  focus. 
This  will  serve  both  to  point  up  the  problems  encountered  and  to  empha- 
size the  fact  that  the  question  attacked  in  this  work  is  very  relevant 
to  at  least  one  real  situation. 

Peerless  is  a  pork-oriented  meat  packer  which  lost  several  millions 
on  sales  of  $300  million  in  fiscal  1966.   For  the  purposes  of  this  study 
Peerless  may  be  considered  to  be  a  pure  price-taker*  in  both  buying 
and  selling,  and  to  have  only  one  plant  (located  in  Cedarton,  Iowa), 
though  neither  is  strictly  true.   The  manufacturing  process  at  Peerless 
begins  with  live  hogs  and  ends  with  several  thousand  finished  products 
ranging  from  whole  fresh  pork  loins,  through  processed  meats  such  as 
bacon,  hams  and  sausage,  to  portion-controlled  frozen  foods. 

In  order  to  balance  out  its  production  process,  Peerless  also 
does  substantial  trading  in  primal  cuts  (major  components  of  hogs,  such 
as  green  (uncured)  hams,  green  bellies,  and  loins).   For  example, 
Peerless  has  a  considerable  consumer  franchise  for  its  bacon,  so  has 
long  been  a  net  buyer  of  bellies;  but  it  is  always  selling  loins,  since 
it  is  weak  in  fresh  meat.   There  are  also  several  components  purchased 
for  use  in  manufacturing,  such  as  cans,  cure,  and  beef  for  sausage. 
Similarly,  many  by-products  are  sold,  including  relatively  unprocessed 


"I.e.  peerless  is  assumed  to  be  unable  to  affect  prices  through 
its  own  actions. 
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ite-ns  like  skin  and  hair,  and  highly  refined  products  like  lard 

A  description  of  the  organization  which  now  solves  the  aggregate 
production  scheduling  problem  for  Peerless  is  in  order;  imbedded  within 
it  will  be  considerable  information  about  the  nature  of  its  production 
process.   We  should  begin  at  the  ena  of  the  production  lines  since 
this  is  a  convenient  aggregation  point  —  many  of  the  thousands  of 
final  products  already  mentioned  differ  from  one  another  only  in  final 
packaging,  and  many  others  are  insignificant  in  volume.  There  are  per- 
haps 300  unique  and  important  final  products. 

The  production  scheduling  function  for  these  final  products  is 
performed  by  several  men  known  as  product  managers.   Each  product  mana- 
ger serves  as  the  interface  between  the  sales  and  production  operations 
for  one  particular  category  of  product.   He  is  responsible  for  translat- 
ing a  demand  figure  supplied  by  sales  into  a  feasible  production  schedule, 
and  for  deciding  what  priorities  should  be  attached  to  each  individual 
product  when  all  demand  cannot  be  met.   He  must  also  cope  with  over- 
stocks, old  meat,  and  so  on.  While  he  does  not  have  the  final  say  on 
pricing,  he  is  always  consulted  before  price  changes  are  promulgated 
and  before  special  marketing  efforts  are  undertaken.  When  the  product 
manager  is  dealing  with  a  perishable  product  such  as  fresh  sausage  (bol- 
ogna, etc.),  his  life  is  complicated  by  short  inventories,  high  spoilage 
costs,  and  market  demand  fluctuations.  When  he  is  dealing  with  a  long- 
lived  product  like  canned  ham,  he  is  spared  some  of  the  day-to-day  fire- 
fighting.   But  he  must  work  against  long-term  forecasts  of  demand  and 
prices,  making  the  daily  decision  as  to  whether  or  not  to  put  meat  into 
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cans,  based  on  his  raw  material  replacement  cost  which  fluctuates 
hourly. 

Each  product  manager  depends  for  his  raw  materials  on  the  provision- 
ers ,  who  are  responsible  for  supplying  primal  cuts  to  the  manufacturing 
operations.   The  provisioners"  major  sources  are  the  internal  kill- 
and-cut  operation  and  the  open  market.   Unfortunately,  every  primal  cut 
is  available  in  several  sizes  at  different  prices  and  different  yields 
in  manufacture.  The  provisioner  cannot  control  the  mix  of  primals  pro- 
duced internally,  but  he  can  control  the  mix  of  purchased  primals;  he 
has  access  to  freezer  space  for  hedging  and  filling  gaps  in  availability, 
and  he  is  responsible  for  selling  any  primals  not  required  by  the  manu- 
facturing operations. 

The  provisioner  has  another  sensitive  duty:  he  must  allocate  finite 
raw  material  resources  among  the  product  managers  in  those  cases  where 
there  is  not  enough  of  a  desirable  size  to  go  around.   This  involves 
substitution  of  other  sizes,  with  corresponding  changes  in  expected 
yields  and  in  the  quality  of  finished  product.   The  provisioner  is  faced 
with  rapidly  varying  prices  for  primals,  both  in  buying  and  selling;  the 
quantities  available  for  purchase  and  wanted  by  potential  buyers  also 
vary  daily.   Finally,  the  quality  of  purchased  primals  is  variable  but 
generally  lower  than  that  achieved  internally  because  of  the  tendency  of 
sellers  to  cull  their  excess  primals  before  offering  the  lower-quality 
ones  to  the  market. 

It  is  not  surprising  that  provisioners  prefer  their  own  product, 
for  which  they  are  dependent  on  the  hog  buyer.  The  hog  buyer  acquires 
hogs  on  the  open  market  for  the  kill-and-cut  operation.   He  determines 
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how  many  hogs  are  to  be  killed  by  day  and  by  weeK.  He  has  considerable 
flexibility  because  there  are  three  ways  to  control  the  daily  rate  of 
kill-and-cut:   overtime,  extra  shifts,  and  chain  speed.  He  need  not 
work  a  full  week,  but  Peerless  pays  each  worker  in  kill-and-cut  for  35 
hours  per  week  at  minimum,  so  he  tries  to  keep  the  facilities  and  men 
busy. 

Hogs  are  a  highly  variable  commodity  and,  while  prices  are  quoted 
on  108  different  sizes  and  grades  of  hog,  each  of  which  tends  to  cut  out 
differently,  the  hog  buyer  has  no  effective  control  over  the  mix  of  hogs 
purchased  at  any  time.  He  is  aided  by  the  law  of  large  numbers  in 
that  the  mix  tends  to  be  relatively  constant  from  day  to  day,  changing 
over  the  year  to  reflect  stages  in  the  growth  cycle. 

The  hog  buyer's  most  potent  decision  tool  is  a  daily  report  show- 
ing the  profit  which  would  have  been  earned  on  every  hog  killed  yester- 
day if  the  hogs  had  been  bought  at  the  Chicago  market  price,  killed  and 
cut  at  exactly  standard  cost,  and  immediately  sold  as  primal  cuts  and 
offal  at  the  Chicago  market  price.   The  usefulness  of  this  tool  is  ob- 
viously limited  by  the  simple  fact  that  Peerless  is  not  primarily  in  the 
business  of  selling  primal  cuts,  and  by  the  fact  that  nothing  is  ever 
done  at  standard  cost,  especially  when  guaranteed  wages  enter  the  picture. 

Thus,  the  hog  buyer  feeds  the  provisioners ,  and  they  feed  the  prod- 
uct managers.   It  is  clear  that  the  provisioning  function  is  the  center 
of  the  whole  operation,  but  the  other  stages  are  also  vital  to  the  pro- 
cess of  production  scheduling.  We  shall  assert  that  this  three-stage 
decision-making  process  is  a  reasonable  attempt  at  coping  with  the  com- 
plexity of  the  manufacturing  process  and  the  uncertainty  of  market  prices. 
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There  are  about  1000  important  levels  to  be  controlled  in  the  con- 
version of  hogs  to  money  at  Peerless,  including  several  hundred  within 
the  production  process  which  arise  from  the  many  alternative  ways  in 
which  one  single  finished  product  can  be  created.   These  make  the  aggre- 
gate production  scheduling  job  entirely  too  much  for  one  man;  but  one 
alternative,  decentralized  decision-making  with  local  data  (cf,  the  hog 
buyer),  is  a  priori  suboptimal. 

In  fact,  the  provisioning  function  at  Peerless  is  currently  handled 
by  several  men  under  the  general  supervision  of  the  Chief  Provisioner 
whose  responsibilities  include  both  "provisioning"  and  "production." 
The  individual  provisioners  have  individual  product-line  responsibility 
and,  except  for  the  odd  phone  call,  they  operate  independently  of  one 
another.   Once  a  week,  they  meet  to  plan  for  the  following  10-day  period. 
Conflicts  are  resolved  by  consultation  among  the  Chief  Provisioner  and 
the  affected  provisioners  and/or  product  managers. 

Using  Carroll's  terminology,  we  may  characterize  the  provisioning 
system  at  Peerless  as  a  set  of  local-real-time  systems,  tied  by  a  loose 
communication  net,  and  supervised  by  a  global-periodic  system  (the 
weekly  meeting).   It  is  doubtful  whether  any  other  organization  would 
be  more  effective.   At  the  risk  of  sloganeering,  we  should  point  out 
that  such  an  arrangement  is  modular  and  open-ended,  and  that  it  permits 
the  Chief  Provisioner  to  manage  by  exception.   Unless  one  wishes  to  com- 
pletely overthrow  the  present  system,  thereby  incurring  what  are  pre- 
sumably large  changeover  costs,  one  must  support  the  local-real-time 
systems  by  means  of  better  plans  and  better  tools  with  which  to  fight 
fires,  and  one  must  support  the  global-periodic  system  with  better  in- 
formation. With  LP,  one  can  supply  the  global-periodic  system  with 
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truly  global,  truly  optimal  results. 

But  the  present  system  permits  the  provisioners  to  gather  when- 
ever there  is  a  crisis  of  sufficient  size  to  justify  a  meeting.   The 
production/provisioning  planning  system  should  also  be  able  to  help  with 
such  ad  hoc  meetings.   Thus,  it  must  be  capable  of  quick  response  as 
well  as  transparent  to  a  variable  time  between  operations  of  the  global- 
periodic  system  (meetings).  We  shall  henceforth  refer  to  the  period 
between  operations  of  the  global-periodic  system  as  the  "planning  inter- 
val." Our  goal  is  thus  an  aggregate  production  scheduling  system  based 
on  LP  and  able  to  operate  with  a  variable  planning  interval. 


Exhibit  I 

GROSS  PRODUCT  FLOW 
PEERLESS  PACKING  COMPANY 
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II. C.   What  the  Provisioner  Needs 

So  far  we  have  considered  the  needs  of  the  provisioner  only  in 
general  terras,  and  this  consideration  has  yielded  a  very  general 
outline  of  the  PPPP  system  needed  to  support  him.   In  this  section,  we 
go  into  further  detail  about  the  role  of  the  provisioner  in  hope 
of  more  tightly  specifying  the  system  required.   We  will  now  use  the 
term  "provisioner"  to  include  the  functions  performed  by  the  hog  buyer 
and  product  managers. 

First,  we  consider  the  routine  global-periodic  provisioning 
functions : 

1.  Acquisition:   How  many  hogs  should  be  purchased?  On 
what  schedule?  In  which  markets?  How  many  of  each  of 
25  types  and  sizes  of  primal  cuts  should  be  purchased? 

2.  Allocation:  How  much  of  each  primal  cut  produced,  pur- 
chased, or  removed  from  the  freezer  should  be  allocated 
to  the  production  of  each  final  product? 

3.  Disposal:   How  much  of  each  primal  cut  should  be  sold  on 
the  open  market?  At  what  price?  On  what  schedule?  To 
whom?  How  much  of  each  primal  cut  should  be  frozen  for 
later  use? 

These  decisions  are  constrained  by  such  factors  as  cash  avail- 
able, primals  available  in  the  market,  demand  for  primals  in  the  mar- 
ket, hogs  available,  plant  capacities,  demand  for  finished  product, 
and  so  on.  They  are  obviously  highly  interactive  one  with  another. 

Now  we  consider  a  sampling  of  local-real-time  provisioning 
functions : 
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k.      Acquisition:  Another  packer  has  offered  us  a  carload  of 
picnics  at  one  cent  off  market  price.   Do  we  accept? 

5.  Allocation:   A  sudden  order  for  a  large  amount  of  some 
finished  product  cannot  be  filled  by  present  stocks  of 
finished  product,  in-process  product,  or  even  allocated 
raw  materials.  Do  we  acquire  more  raw  materials?  Do  we 
acquire  more  raw  materials  (primals),  substitute  another 
size  of  the  needed  primal,  refuse  the  order,  or  do  some 
combination  of  these? 

6.  Disposal:  A  carload  of  loins  is  growing  old,  but  at 
present  market  price  we  take  a  loss  of  two  cents  on  each 
pound.   Do  we  sell  at  a  loss? 

7.  Price  Change:  Green  hams  are  up  two  cents  this  morning. 
We  suspect  that  this  is  a  temporary  rise  which  will  never 
be  reflected  in  increased  price  for  finished  product.   Do 
we  suspend  ham  processing  and/or  sell  off  our  green  hams? 

We  now  proceed  to  describe  what  will  be  referred  to,  for  want  of 
a  better  term,  the  "ideal"  PPPP  system.   In  so  doing  we  indulge  in  two 
fantasies.   First  we  assume  that  the  payoff  from  the  use  of  this  system 
will  justify  its  running  cost.   For  this  purpose  we  assume  that  it  will 
consume  about  I/8  of  the  available  time  on  a  data-processing  system 
costing  $^00,000/year,  or  $50,000  in  data-processing  costs/year.   In 
addition,  we  allow  $50,000  more  for  maintenance  and  special  data  collec- 
tion. Routine  data-collection  costs  are  assumed  to  be  absorbed  else- 
where (as  described  below).   In  order  to  justify  its  costs  then,  it 
must  save  (or  produce)  $100,000/year,  or  0.04^  of  sales.   Our  second 
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fantasy  is  to  assume  that  Peerless  can  support  the  $400,000  data  process- 
ing system  mentioned  above.   This  is  about  0.l6^  of  sales  and  is  not 
a  priori  unreasonable,  but  it  is  unreasonable  in  Peerless'  present 
situation.  Nonetheless,  we  must  assume  it  for  now. 

Several  more  assumptions  are  necessary,  all  of  which  are  reasonable. 
First  we  assume  that  certain  key  pieces  of  data  are  available  at  little 
incremental  cost  from  the  accounting  system.  When  this  project  was 
begun  Peerless  was  in  the  process  of  building  and  implementing  PYRAMIDS 
(Plant  Yield  Reporting  and  Management  Information  Dissemination  System). 
PYRAMIDS  (which  at  this  writing  is  in  regular  operation)  was  to  contain 
all  price,  inventory,  shipment,  and  yield  information  as  a  matter  of 
course,  thus  eliminating  the  need  for  a  separate  routine  data  collection 
for  PPPP. 

Finally,  we  adopt  a  convention  for  describing  the  LP  model  on  which 
the  PPPP  system  is  based.   The  model  will  be  described  in  terms  acceptable 
to  the  "bounded  variable  algorithm"*  in  which  upper  and  lower  bounds  may 
be  attached  directly  to  the  columns,  primarily  because  the  majority  of 
limitations  encountered  in  formulating  this  model  appropriately  affect 
only  a  single  column.   In  the  few  cases  where  a  real  inequality  row 
is  needed,  it  costs  only  one  new  column  to  convert  it  to  an  equality 
row  with  explicit  bounds  on  the  newly-created  column.   This  results  in 
a  much  more  compact  model  (in  this  case,  there  would  be  25OO  or  more 
rows  if  every  bound  required  a  new  row),  and  means  that,  since  every  row 
is  a  structural  equality  not  subject  to  the  control  of  management ,  the 


►Hadley  (3). 
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important  shadow  prices  —  those  for  real  resources  —  are  grouped 
naturally  with  the  remaining  information  about  the  columns.  Thus  the 
user  need  not  maintain  any  sort  of  dictionary  to  guide  him  from  a  par- 
ticular column  to  corresponding  bound  rows.  The  compactness  means 
that  the  model  can  be  made  to  work  on  a  smaller  machine  than  would 
otherwise  be  required,  though  no  reduction  in  solution  time  is  implied. 
The  output  is  somewhat  more  compact,  since  it  is  unnecessary  to  present 
information  about  the  rows.   For  all  these  reasons,  the  model  will  be 
built  and  maintained  as  if  it  were  in  the  bounded  variable  form,  even 
though  it  may  well  be  run  on  a  machine  for  vrtiich  no  such  code  currently 
exists. 

Having  established  some  assumptions  and  conventions,  we  now  describe 
the  ideal  PPPP  system.   To  reiterate,  it  is  basically  a  global-periodic 
system  whose  period  can  vary,  and  is  designed  to  aid  a  provisioner  in 
tasks  like  the  seven  mentioned  above.   As  described,  it  will  begin  to 
appear  more  and  more  like  an  on-line,  real-time  system.   This  is  not  sur- 
prising since  a  global-periodic  system  with  sufficiently  short  period 
is,  in  effect,  an  on-line,  real-time  system. 


26 


II. D.   The  Ideal  System:  General  Philosophy 

One  possible  requirement  on  the  ideal  system  is  that  it  dominate 
the  present  system.   This  is  relatively  easy  to  accomplish,  since  it 
is  always  possible  to  invoke  the  present  system  for  any  task  which  is 
better  accomplished  by  present  methods.  However,  the  power  of  the 
present  system  comes  in  some  part  from  the  fact  that  the  individual 
provisioners  are  always  in  possession  of  quite  recent  information  about 
the  current  status  of  their  product  areas.   So  an  obvious  requirement 
on  the  ideal  system  is  that  it  supply  provisioners  with  information  at 
least  as  current  as  what  they  now  have  and,  conversely,  that  they  be 
able  to  supply  it  with  current  information  when  such  would  help.   Along 
this  dimension,  the  ideal  system  looks  like  an  information  storage  and 
retrieval  system. 

Another  desirable  characteristic  is  that  the  system  be  able  to 
answer  such  questions  as  "What  would  happen  if  an  extra  carload  of 
bellies  were  made  available  to  the  plant?"  This  is  the  essential  char- 
acteristic of  a  simulation  system. 

And,  we  want  to  be  able  to  ask  the  system  for  the  optimal  plan 
for  the  following  week,  based  on  current  or  projected  information.   In 
this  regard,  we  are  talking  about  a  conventional  optimization  technique. 

Since  the  Chief  Provisioner  can  call  a  special  meeting  to  invoke 
the  present  system  at  any  time,  it  is  not  unreasonable  to  expect  the 
ideal  system  to  respond  as  quickly.   So  the  ideal  system  must  consist 
of  data-collection  and  editing  subsystems,  an  optimization  subsystem, 
and  report  generation  subsystems.   It  must  operate  as  a  true  on-line 
system  or  at  worst  as  a  batch  system  with  rapid  turn-around  to  provide 
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the  requisite  level  of  response  time. 

The  following  sections  describe  the  required  subsystems.  The 
descriptions  are  written  as  if  the  data-processing  system  available  had 
massive  random-access  storage  capability  and  the  ability  to  create  and 
use  symbolically-named  files.  While  neither  of  these  features  is 
strictly  necessary,  both  are  great  conveniences  for  the  system  designer. 
The  descriptions  also  assume  a  command  language  which  can  be  used  to 
drive  the  subsystems.  Such  command  languages  are  an  integral  part  of 
modern  remote-job-entry  oriented  operating  systems  such  as  OS/36O  and 
EXEC/8,  and  no  extraordinary  effort  is  likely  to  be  required  to  adapt 
the  operating  system  to  the  needs  of  the  PPPP  system. 
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II. E.   The  Ideal  System:  Data  Generation  and  Editing 

The  data-generation  and  editing  subsystems  have  at  least  the 
following  capabilities: 

1.  FORECAST: 

Using  the  PYRAMIDS  files  of  shipment  and  order  data,  the 
system  generates  forecasts  of  sales  for  all  finished  products 
for  some  arbitrary  period.   It  places  these  forecasts  in  a  file 
called: 

MACHINE  .  FORECASTS  .  MMDD 
where  MMDD  is  today's  date. 

2.  FCSTUPDATE: 

The  system  delivers  the  information  in  the  latest  file 
named  MACHINE  .  FORECASTS  .  MMDD  or  HUMAN  .  FORECASTS  .  MMDD 
to  the  user's  console  or  remote  printer.   It  then  accepts  the 
user's  revisions  to  these  forecasts.   It  enters  the  modified 
forecasts  in  a  file  called: 

HUMAN  .  FORECASTS  .  MMDD 

3.  MODSTRUCTURE  ALPHA  BETA 

The  system  accepts  changes  to  the  LP  structural  equations 
contained  in  file 

ALPHA  .  STRUCTURE 
and  places  the  changed  structural  equations  in  file 

BETA  .  STRUCTURE 
k.      DRAWSTATUS  GAMMA  DELTA 

The  system  searches  the  file 

GAMMA  .  STRUCTURE 
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to  find  what  price  and  quantity  information  is  required  to  run 
the  model.   It  then  searches  the  PYRAMIDS  file  and  the  latest 
version  of 

HUMAN  .  FORECASTS  .  MMDD 
to  fill  in  prices  and  quantities.   Some  prices  will  require 
special  manipulation.  For  example,  PYRAMIBS  keeps  all  prices 
as  positive  numbers.   Some  will  need  to  be  made  negative  for  the 
purposes  of  the  LP.   In  the  case  of  long-life  products,  some  de- 
duction from  selling  price  will  be  required  to  account  for  holding 
costs  until  expected  sale.  For  guidance  in  these  operations, 
the  system  will  refer  to  file 

DELTA  .  PRICERULES 

The  result  will  be  a  complete  LP  problem  ready  to  be  run  in 
the  file 

GAMMA  .  STATUS 

It  can  be  argued  that  this  subsystem  permits  great  generality 
in  model  structure  (via  MODSTRUCTURE)  and  in  price  manipulation 
(via  DRAWSTATUS),  but  that  it  is  slavishly  tied  to  price  and 
quantity  information  contained  in  the  PYRAMIDS  files.  This  is 
desirable  because  the  PYRAMIDS  files  must  be  correct  for  proper 
functioning  of  the  accounting  system.  However,  to  correct  the 
occasional  error  and  to  allow  the  user  to  try  out  "What  would 
happen  if  ...  "  questions,  we  also  require: 
EDSTATUS  GAMMA  EPSILON 

This  permits  the  user  to  change  the  information  in  GAMMA 
STATUS,  filing  the  result  as  EPSILON  .  STATUS. 
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II. F.   The  Ideal  System:   Optimization 

The  optimization  subsystem  supports  the  single  command: 

OPTIMIZE  GAMMA 

The  system  takes  the  file 

GAMMA  .  STATUS 
and  converts  it  into  the  required  input  format  for  the  manufacturer's 
LP  package.  The  LP  code  then  taKes  over,  returning  control  to  the 
OPTIMIZE  command  when  done.  This  output  is  then  filed  under  the  name 

GAMMA  .  SOLUTION 
It  is  worthwhile  to  note  here  that  one  would  not  normally  write  his  own 
LP  package,  because  many  major  manufacturers  (IBM,  CDC,  UNIVAC,  etc.) 
supply  truly  excellent  LP  codes  for  their  larger  machines.  Such  codes 
are  characterized  by  large  capacity,  availability  of  comprehensive 
start-up  and  post-optimality  procedures,  and,  just  as  important,  embody 
control  languages  allowing  a  limited  amount  of  external  logic  to  be 
performed  by  the  code  itself.   Thus  special  procedures  in  case  of  in- 
feasibility  or  wildly  unlikely  solutions  can  be  specified  by  the  user 
as  part  of  his  input. 

The  actual  form  of  the  model  to  be  optimized  for  Peerless  is  left 
to  Chapter  III  and  its  appendix.  However,  it  is  certain  that  the  model 
should  include  all  important  controllable  levels  for  Cedarton  operations, 
and  that  the  output  should  include,  besides  normal  recommended  activity 
levels  and  reduced  costs,  the  post-optimal  cost  and  constraint  ranges. 
The  latter  will  be  helpful  in  answering  questions  about  marginal 
activity  (see  questions  4  and  7  in  Section  II. C).   In  addition,  full 
advantage  should  be  taken  of  any  special-purpose  output  (such  as 
infeasibility  traces),  in  case  of  trouble  in  solution. 
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II. G.   The  Ideal  System:   Report  Generation 

The  report  generation  subsystem  has  at  least  the  following  capa- 
bilities : 
1.   REPORT  GAMMA  ZETA 

Produces  for  the  user  a  report  of  the  model  described  in 
GAMMA  .  STATUS.   For  each  column  of  the  model  (remember  that  we 
have  no  need  for  row  information),  the  report  should  contain: 
Alphabetic  description  of  the  variable 
Objective-Function  Coefficient  (price) 
Lower  Bound  if  Any 
Upper  Bound  if  Any 
Recommend  Level  (Solution  Value) 

Activity  Status  (In  solution  or  not,  at  upper/lower  bound) 
Maximum  Price  (Algebraically  maximum  value  of  objective 
function  coefficient  at  which  this  column's  solution 
status  remains  unchanged) 
■  Activity  Limiting  Maximum  Price 
Solution  Status  of  Limiting  Activity 
Minimum  Price 

Activity  Limiting  Minimum  Price 
Solution  Status  of  Limiting  Activity 
Marginal  Return  for  Increase  (Net  Change  in  Objective  Function 

for  One-Unit  Increase  in  Activity  Level) 
Maximum  Level  (Before  Marginal  Return  for  Increase  Will  Change) 
Activity  Limiting  Maximum  Level 
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Solution  Status  of  Limiting  Activity 

Marginal  Return  for  Decrease  (Probably  has,  but  may  not  have, 
same  magnitude  and  opposite  sign  as  Marginal  Return  for 
Increase) 
Minimum  Level 

Activity  Limiting  Minimum  Level 
Solution  Status  of  Limiting  Activity 
This  represents  most  of  the  information  available  about  a  solution 
short  of  parametric  runs.   It  suffices  to  allow  the  user  to: 

a.  Base  a  plan  on  the  recommended  levels 

b.  Base  marginal  decisions  on  the  Price-and-constraint  range  in- 
formation. 

In  order  to  prepare  this  report,  the  system  vd.ll  have  to  use  both 
files 

GAMMA  .  SOLUTION 
and 

GAMMA  .  STATUS 

For  convenience  in  later  use,  the  complete  report  should  be  placed 

in  a  file 

GAMMA  .  REPORT 

It  is  likely  that  the  user  will  wish  to  suppress  some  of  the  output 

and/or  utilize  aggregation  techniques.   In  order  to  allow  this,  the 

REPORT  command  allows  the  parameter  ZETA  which,  if  present,  causes  the 

system  to  build  the  user's  report  according  to  tables  stored  in  file 

ZETA  .  FORMAT 
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2.  COMPARE  GAMMA  OMEGA  ZETA 

Using  the  report  files  from  two  solutions  i.e. 

GAMMA  .  REPORT  and 

OMEGA  .  REPORT, 
the  system  prepares  a  difference  report  according  to 

ZETA  .  FORMAT 
and  presents  this  to  the  user. 

3.  PLAN  GAMMA  IOTA 

The  system  presents  file  -  ■ 

GAMMA  .  REPORT  or 
GAMMA  .  PLAN 
to  the  user,  who  enters  planned  levels  and  prices  wherever  his 
plan  differs  from  the  levels  and  prices  in  the  input  file.  When- 
ever he  does  not  enter  a  new  value,  the  number  given  in  the  input 
file  is  taken  as  the  planned  number.   The  result  is  filed  under 
the  name 

IOTA  .  PLAN 

4.  CONTROL  IOTA  ZETA 

The  system  searches  the  PYRAMIDS  files  for  actual  performance  fig- 
ures (amount  produced  or  allocated,  prices  realized,  etc).  It 
then  searches 

IOTA  .  PLAN 
for  the  planned  numbers  and  produces  a  control  report  contrast- 
ing planned  and  achieved  numbers,  according  to  format  file  ZETA. 
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II.  H.   How  the  Ideal  System  is  Used 

Let  us  suppose  that  the  system  is  now  in  use.  The  current  plan  is 

based  on  files 

CURRENT  .  STATUS 

CURRENT  .  SOLUTION 

CURRENT  .  REPORT 

CURRENT  .  PLAN 

NORMAL  .  PRICERULES 

CURRENT  .  STRUCTURE 

NORMAL  .  FORMAT 

and  is  now  a  week  old.  It  is  time  to  prepare  next  week's  plan.  The 
sequence 

FORECAST 

FCSTUPDATE 

has  been  run.  Slight  changes  are  expected  in  plant  yields  due  to  a 

change  in  the  average  characteristics  of  hogs  available;  so,  we  have 

to  modify  the  structural  equations  of  the  model  accordingly.   Therefore 

we 

M0D3TRUCTURE  CURRENT  NEXT 
DRAWSTATUS  NEXT  NORMAL 
OPTIMIZE  NEXT 
REPORT  NEXT  NORMAL 
COMPARE  CURRENT  NEXT  NORMAL 

Examining  the  difference  report  comparing  CURRENT  and  NEXT,  we  see 

that  several  quantities  have  changed  greatly.   On  further  investigation, 

we  see  that  prices  for  2  primals  have  been  reversed  in  the  PYRAMIDS  file. 

We  cope  by  issuing 

EDSTATUS  NEXT  NEXT 
OPTIMIZE  NEXT 
REPORT  NEXT  NORMAL 
COMPARE  CURRENT  NEXT  NORMAL 
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This  time,  our  examination  convinces  us  that  the  model  NEXT  is 

satisfactory.  We,  therefore,  hold  our  weekly  planning  meeting  during 

(or  at  the  conclusion  of)  which  we  issue 

PLAN  NEXT 

and  enter  the  plan  for  the  week  ahead. 

From  this  point  on,  any  product  manager  or  provisioner  can  find 

out  the  current  plan  and  how  he  is  doing  in  comparison  by  issuing, 

say, 

CONTROL  NEXT  HAMS 

where  the  file 

HAMS  .  FORMAT 

contains  instructions  to  select  just  the  ham  sector  of  the  report. 

Now  suppose  the  provisioner  wants  to  know  whether  or  not  to  accept 

an  extra  carload  of  picnics.  In  most  cases,  the  regular  report  gives 

him  the  marginal  value  of  extra  picnics.   If  he  doesn't  feel  confident 

about  this,  however,  he  can  try 

EDSTATUS  NEXT  SPECIAL 

and  create  a  new  file 

SPECIAL  .  STATUS 

containing  the  information  that  extra  picnics  are  available.   He  then 

issues : 

OPTIMIZE  SPECIAL 
REPORT  SPECIAL  NOPAPER 
COMPARE  SPECIAL  NEXT  NORMAL 

where  the  file 

NOPAPffi  .  FORMAT 

suppresses  actual  production  of  the  regular  report,  but  does  allow 
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creation  of  the  necessary  file 

SPECIAL  .  REPORT 

He  must  be  aware  that  the  sequence  above  compares  only  two  recom- 
mended solutions,  not  two  plans,  but  he  does  get  an  excellent  idea  of 
the  consequences  of  accepting  the  extra  picnics. 

The  system  as  described  above  is  thus  able  to  answer  virtually  all 
questions  of  the  type  posed  in  Section  II. C   In  addition,  we  need  only 
require  that  forecast  information  and  realization  information  (the  lat- 
ter from  PYRAMIDS)  be  converted  into  weekly  rates  to  make  the  system 
absolutely  transparent  to  whether  planning  is  done  daily,  weekly, 
monthly,  or  at  any  intermediate  interval. 

The  system's  response  time  is  of  course  dependent  on  the  speed  and 
size  of  the  machine  (s)  on  which  it  is  resident,  and  also  on  its  mode 
of  operation  (on-line,  remote  batch,  normal  batch,  etc.);  but,  in  most 
cases,  one  day  would  seem  to  be  an  upper  bound  on  a  complete  re-planning. 
Moreover,  such  a  system  could  surely  be  implemented  on  a  machine  in  the 
size  class  of  a  large  360/40  (12  8  K  bytes)  with  good  random-access  capa- 
bility.  Such  a  machine  might  cost  roughly  $200,000/year  for  rental  alone. 

On  the  other  hand,  such  a  system  would  be  expensive  to  build.   (How 
expensive  it  would  be  is  impossible  to  estimate  at  this  level  of  detail 
in  description  and  without  a  particular  machine  and  operating  system  in 
mind.)  Once  built,  system  maintenance  would  be  modest,  since  the  system 
itself  consists  mainly  of  very  general  data-manipulation  subsystems. 
Maintenance  of  the  data  base  is  largely  absorbed  by  PYRAMIDS.  The  major 
flaw  in  this  "ideal"  system  is  that  its  use  would  require  either  some 
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substantial  change  in  the  roles  of  the  provisioners  or  the  interposi- 
tion of  a  cadre  of  technicians  between  them  and  the  system.  While 
neither  is  strictly  desirable,  the  latter  alternative  is  costly  and 
likely  to  introduce  errors.  In  the  long  run,  the  provisioners  probably 
would  find  it  desirable  to  become  intelligent  system  users  themselves. 

There  will  have  to  be  technicians,  of  course,  to  step  in  when 
solutions  are  infeasible,  unbounded,  or  unreasonable.  These  people  should 
preferably  combine  computer,  LP,  and  provisioning  expertise.  Their 
salaries  are  part  of  the  cost  of  running  this  system. 
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II. J.   Variable  Planning  Interval  Considerations 

To  this  point  in  Chapter  II,  we  have  defined  a  problem  area  amen- 
able to  LP  solution  if  and  only  if  the  LP  system  can  be  made  "quick  to 
respond. "  We  have  proposed  a  supporting  system  which  would  allow  the 
LP  system  to  respond  in  time  on  the  order  of  sorae  small  multiple  of 
the  actual  time  taken  for  an  LP  solution.   The  system  is  designed  to 
support  a  mix  of  global-periodic  and  local-real-time  activities,  and 
it  is  genuinely  transparent  to  the  periodicity  of  its  global-periodic 
function,  subject  to  a  minimum  of  one  day  (less  if  PYRAMIDS  updates 
its  files  more  often). 

We  now  ask  v^ether  we  can  put  bounds  on  what  is  "quick  enough," 
and  we  assert  that  the  system  must  be  "quick  enough"  along  both  the 
global-periodic  and  local-real-time  dimensions.  We  suggest  that  the 
system  is  "quick  enough"  if: 

1.  In  support  of  global-periodic  activity,  it  can  go  through  a  com- 
plete re-plan  in  a  time  approximately  equal  to  the  minimum  period 
between  plans  (in  this  case,  one  day);  and 

2.  In  support  of  local-real-time  activity,  it  can  answer  the  average 
question  at  least  as  quickly  as  the  present  system  does. 

It  is  tempting  to  put  an  upper  limit  on  the  time  taken  to  answer  any 
question  in  support  of  local-real-time  activity.   That  is,  to  define 
"quick  enough"  in  terms  of  a  worst-case  as  well  as  an  average.  This 
is  fallacious,  since  the  provisioner  can  always  invoke  the  present 
system  where  needed,  provided  that  his  information  is  at  least  as  good 
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as  he  now  has  and  provided  he  knows  where  the  system  will  be  slow. 
Extending  this  notion  just  slightly,  we  can  see  that  the  system  is 
useful  if  it  can  answer  any  one  class  of  question  faster  than  the  pres- 
ent system,  providing  that  the  provisioner  is  able  to  recognize  a 
question  of  that  class.   This  does  not  imply  that  the  system  is  worth 
its  cost,  however. 

Now,  the  notion  of  average  question  implies  some  mix  of  tasks 
performed  by  the  local-real-time  system.  While  it  would  be  nice  to 
know  that  mix,  the  provisioners  themselves  are  by  no  means  sure  what 
it  is,  and  we  can  draw  some  interesting  conclusions  without  knowing  it. 

First,  there  is  a  class  of  question  which  is  answerable  instantly. 
A  trivial  example  is  "Kow  many  4-6  lb.  picnics  do  we  expect  from  our 
own  hogs  this  week,  and  are  we  selling  them?"  Provided  that  the  most 
recent  plan  is  being  followed,  the  answer  is  right  there  on  the  provis- 
ioner 's  copy  of  the  plan  report. 

Some  not-so-trivial  questions  can  also  be  answered  instantly. 
"Can  I  accept  a  carload  of  picnics  at  two  cents  off  market?"  If  we 
have  a  new  solution/plan,  the  provisioner  looks  at  the  Marginal  Return 
for  Increase  for  such  picnics.   Suppose  it  is  -.011  assuming  market 
price.   At  two  cents  off,  then,  it  is  .009  or  almost  a  penny  a  pound. 
He  now  looks  at  the  Maximum  Level.   Suppose  it  is  40,000  pounds  more 
than  the  Recommended  Level.  He  can  easily  absorb  a  35.000  pound  carload 
at  a  net  profit  of  .009  x  35,000  or  $315.  This  is  another  instant  answer. 


*"I  can  do  all  right  on  the  back  of  an  envelope  if  you  don't  take 
my  envelopes  away."  Peerless'  Chief  Provisioner. 
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Thus,  one  important  principle  is: 

The  more  information  we  give  the  provisioner  about  a  given 
solution/plan,  the  more  questions  he  can  answer  instantly  and  the 
lower  is  the  system  response  time  to  the  average  question. 

Now,  let  us  consider  the  carload  of  picnics  above  in  more  detail. 
In  all  probability,  such  a  transaction  does  not  seriously  affect  any 
product  area  except  picnics.   This  is  because  the  various  product  areas 
interact  only  slightly  with  one  another  under  most  circumstances.   But 
the  current  solution/plan  for  picnics  is  certainly  suspect  just  as  soon 
as  the  extra  carload  is  acquired.   Possibly,  the  arrival  of  these  extra 
picnics  will  justify  killing  fewer  hogs,  which  would  affect  everything, 

but,  far  more  likely,  all  that  happens  is  that  the  provisioner  loses 
confidence  in  the  picnic  sector  of  his  plan.   Thus  another  important 
principle  is: 

The  more  actions  that  are  taken  which  move  actuality  away 
from  the  plan,  and,  of  course,  the  more  exogenous  changes  (such 
as  of  price,  availability,  etc.),  the  more  likely  it  is  that  a 
given  "instant  answer"  is  incorrect  and  the  smaller  the  class  of 
questions  which  can  be  answered  instantly.  We  will  call  this  effect 
"solution  decay,"  after  Carroll. 

We  find  ourselves  treading  a  fine  line,  then.   On  one  hand,  the 
more  information  we  give  the  provisioner,  the  quicker  he  can  answer  the 
average  question.  On  the  other  hand,  the  more  decisions  affecting  the 
current  plan  taken  by  the  provisioner,  the  more  of  that  same  expensive 
information  becomes  obsolete.  All  such  problems  are  solved  by  a  complete 
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re-plan,  of  course,  but  that  is  expensive.  What  is  needed  is  the  op- 
timal strategy  for  disseminating  information  and  determining  when  to 
re-plan. 

The  next  two  sections  describe  two  approaches  to  the  problem  of 
when  to  invoke  the  LP  for  re-planning.  The  first  (Section  II. K)  in- 
vokes a  model  which  was  developed  and  abandoned  because  it  could  not 
be  made  useful  without  substantial  operating  experience.  The  second 
(Section  ILL)  involves  a  scheme  of  joint  man-machine  decisions  about 
re-planning,  designed  to  give  us  satisfactory  operation  while  more  data 
about  the  process  could  be  gathered. 
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U.K.   Strategies  for  Re-Planning 

Now  we  will  consider  the  question,  "How  can  the  user  tell  when 
he  should  re-plan?"  or,  at  what  point  does  the  current  plan  become 
obsolete?  One  possible  approach  is  to  aevelop  an  optimal  periodicity 
for  the  system  (call  it  Topt).   Our  most  basic  assumption  is  that  while 
the  value  of  Topt  in  January  may  be  wildly  different  from  the  value 
in  May,  Topt  changes  little  between  two  consecutive  days  in  January  or 
May.  We  also  assume  that  changeover  costs  are  absorbed  in  the  cost  of 
planning.  It  is  now  necessary  to  determine  what  cost  function  is  to 
be  minimized. 

Certain  costs  are  independent  of  Topt.   Data-collection,  especially 
forecasting,  will  go  on  regardless  of  how  often  the  planning  system 
is  run,  for  example. 

Now  let  us  consider  the  components  of  the  cost  function  which  d£ 
depend  upon  Topt.   Let  the  number  of  columns  in  our  LP  model  be  N  and 
the  number  of  rows  (including  implicit  rows  generated  by  bounded 
variables)  be  a  constant  fraction  of  N.  We  then  have  the  following 
components  of  the  cost  of  drawing  a  plan: 

"^       2 

Cp  =  K-^W      +     K2N   +   (Ki  +  U(S))N  +  Ko 

Where  the  K's  are  constants  and  U(S)  is  a  function  relating  cost 
of  report  generation  to  the  subset  S  of  output  selected  for  each  plan. 

The  term  in  N^  comes  from  the  OPTIMIZE  subsystem,  the  term  in  N 
from  OPTIMIZE  and  data  transmission  functions. 

Assuming  that  we  use  the  system  only  for  planning  and  that  nothing 
ever  happens  over  the  period  Topt  to  make  reality  differ  from  tne  plan. 
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our  total  cost  is  just  Cp/lopt  per  day.   Of  course,  things  do  happen 
to  change  reality.  Let  us  call  each  such  event  a  "glitch,"  and  let  us 
assume  that  the  number  arriving  every  day  fits  a  Poisson  distribution 
of  parameter  m,  taken  to  be  constant  over  Topt.   Now  a  glitch  is  just 
a  potential  non-optimal ity;  i.e.  a  glitch  is  a  situation,  which,  if 
not  attended  to,  may  cause  us  to  incur  unnecessary  costs  or  forgo  extra 
profits.   So,  with  some  probability  Pg  we  should  cope  with  the  glitch, 
and  with  probability  1  -  Pg  we  should  not.   If  we  should  cope  with  the 
glitch  and  do  not,  we  incur  a  regret  (increased  cost  or  forgone  profit) 
of  Cg/day,  where  Cg  is  drawn  from  some  distribution. 

Some  examples  are  in  order.   Suppose  the  price  of  a  particular 
finished  product  declines.  We  were  already  making  as  little  as  possible. 
This  is  a  "non-cope  glitch."  We  will  lose  money  but  there  is  nothing 
we  can  do  about  it,  so  the  cost  is  not  part  of  our  cost  function  to  be 
minimized.   On  the  other  hand,  suppose  the  price  of  the  same  product 
were  to  rise  (high  enough  to  justify  making  more).  This  is  a  "cope 
glitch."   If  we  did  not  make  more  we  would  be  no  worse  off  than  before, 
but  we  would  forgo  extra  profit  which  would  create  a  regret  for  our 
cost  function. 

We  must  emphasize  that  the  Cg  belonging  to  each  glitch  has  nothing 
to  do  with  whether  or  not  profit  is  increased  or  decreased  by  it,  but 
depends  only  on  what  it  does  to  our  position  relative  to  the  best  possi- 
ble position. 

As  our  plan  ages  and  we  experience  solution  decay,  some  glitches 
occur  which  have  negative  Cg;  that  is,  they  tend  to  move  us  toward  op- 
timality.  These  are  special  forms  of  the  non-cope  glitch.  They  do  con- 
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tribute  to  solution  decay,  and  they  do  reduce  the  amount  of  non-optimal- 
ity  costs  incurred,  but  they  do  not  require  action.- 

Given  this  somewhat  fanciful  structure,  what  are  the  components  of 
solution  decay?  This  depends  on  whether  we  measure  solution  decay  in 
terms  of  dollars  or  in  terms  of  lessened  information.   If  the  former, 
and  if  we  never  cope  with  glitches,  the  expected  solution  decay  in  dol- 
lars is  given  by: 

SDD(T)  =  mPgE(Cgt) 

where  E(Cgt)  is  the  expected  value  of  Cg  on  day  t  of  a  plan.   (Dimen- 
sionally,  SDD(T)  is  in  dollars/day.)   In  general  we  expect  E(Cgt)  to 
decline  with  increased  solution  decay,  thus  with  increased  t. 

The  total  cost  of  solution  decay  over  the  period  Topt  is  then: 


Tqp^t  Topt 

CSD(topt)  =   ^L_  SDD(T)  .  (Topt-T  =   ^n^   [(Topt-t)  .  raPgE(Cgt)/ 
T=0  t=0  ^ 

Thus  the  total  daily  cost  is: 


IK3N-'  +  K2N  +  (Ki  +  U(S))N  +  Ko  +  "^l  ((Topt-t)  .  raPgE(Cgt)] 

t=0 

assuming  Pg  constant. 

We  now  wish  to  add  the  costs  and  results  of  coping  with  each  in- 
coming glitch.  We  observe  that  we  will  cope  with  some  proportion  Rgt 
of  all  incoming  glitches.  But  each  cope  costs  something  unless  it  is 
in  the  "instant  answer"  category.  Let  us  call  the  probability  that  a 
cope  costs  nothing  Z(T,S,N),  recognizing  that  this  depends  on  the  age 
of  our  plan,  the  set  of  information  given  by  our  reports,  and  the  com- 
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plexity  of  the  model.   If  a  cope  does  cost  something,  it  will  be  of 
order  Cp;  call  it  HCp. 
Now,  on  each  day: 

m  glitches  arrive; 
mPg  deserve  coping; 
mRgtPg  are  coped  with 
The  cost  is: 

HCpd  -  Z(t,S,N))RgtPgm 
(1  -  Rgt)  Pgm  are  not  coped  with. 
The  cost  is: 

(1  -  Rgt)mPgE(Cgt)  .  (Topt  -  t) 
So  the  total  cost  per  day  is: 

(  Topt  ^ 

Cp  +  >   [HCp(1  -  Z(t,S,N))raRgtPg  +  (1  -  Rgt)mPgE(Cgt)  .  (Topt-t)J  /Topt 

=  Y^^   +  K2N^  +  (K^  +  U(S))N  +  Kq]  \\   +  HmPg  s__  Rgt(l  -  Z(t,S,N))] 

Topt  > 

+  raPg    \_      [(1   -  Rgt(E(Cgt)    .    (Topt   -   t)]  j/Topt 

t=0  ) 

Note  that  E(Cgt)  does  not  decline  so  fast  with  time  as  if  we  were  not 

coping,  since  we  remain  closer  to  optimum. 

We  now  have  a  cost  function  which,  if  minimized,  will  yield  Topt 

and  N.  We  will  not  attempt  this,  because  too  many  of  the  parameters  in 

this  already  oversimplified  model  are  impossible  to  measure  except  over 

a  very  long  period  of  system  operation.   Our  task  is  to  get  a  system 

operating  and,  in  order  to  do  so,  we  will  adopt  a  replanning  scheme 

involving  a  combination  of  machine  and  human  pattern-recognition. 
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ILL.  Re-Planning  on  Demand 

The  re-planning  scheme  adopted  is  one  in  which  the  machine  system 
(still  tne  "ideal"  system)  and  its  human  users  take  the  decision  to 
re-plan  based  on  their  aggregate  discomfort  with  the  present  plan- 
First,  we  describe  the  human  sector.   As  a  plan  grows  older  and 
as  solution  decay  builds  up,  it  becomes  progressively  less  likely  that 
a  given  question  is  in  the  "instant  answer"  category.   So  more  and  more 
questions  will  either  go  unanswered  or  require  resort  to  the  machine 
system  for  a  sequence  of:  ^-     • 

EDSTATUS 
OPTIMIZE  ■ 
REPORT 
COMPARE 

Presumably,  the  human  user  thus  becomes  increasingly  uncomfortable 
with  the  current  plan  until  he  is,  in  effect,  driven  to  initiate  a  re- 
planning  sequence. 

The  machine  system  has  quite  a  different  way  of  perceiving  discom- 
fort.  It  can  scan  the  PYRAMIDS  files  periodically  to  determine  if: 

-  The  price  of  any  single  variable  lies  outside  its  proper  range; 

-  The  prices  of  two  or  more  basis  variables  have  changed; 

-  The  bounds  on  any  variable  have  changed  to  make  its  planned 
value  infeasible; 

-  The  bound  on  any  non-basis  variable  has  changed  so  as  to  allow 
a  desirable  modification  in  planned  quantity. 

If  none  of  the  above,  then  no  action  is  necessary.   If  any  of  the 
above,  the  system  must  produce  a  new  status  file  and  attempt  a  condi- 
tional optimization  (keeping  the  current  basis  but  substituting  the 


47 

new  prices  and  bounds).  One  of  three  results  must  occur: 

1.  Solution  is  still  feasible-optimal.   The  system  produces  a 
solution  file  and  informs  the  user  of  „his;  recommended 
levels  may  have  changed,  but  the  status  of  all  variables 
has  not  changed  and  probably  only  minor  adjustments  are 
required  in  the  plan. 

2.  Solution  is  feasible,  non-optimal.   The  system  informs  the 
user,  who  may  want  to  ignore  minor  non-optimality;  otherwise, 
the  user  can  continue  the  re-planning  sequence. 

3.  Solution  is  infeasible.   System  completes  optimization  and 
informs  user;  profound  changes  are  possible. 

In  any  of  these  cases,  the  system  should  give  the  user  the  value 
of  the  new  objective  function  and  the  value  of  the  profit  function,  con- 
sisting of  the  old  planned  quantities  and  the  new  actual  prices.  This 
gives  the  user  an  approximation  to  the  regret  incurred  by  not  completing 
the  re-planning  process  —  however,  it  is  only  an  approximation  because 
the  old  planned  quantities  may  well  be  infeasible.  To  help  the  user 
estimate  how  large  this  effect  may  be,  he  should  also  be  given  the  value 
of  the  old  objective  function  so  that  he  can  isolate  the  effects  of 
changes  in  price  from  those  of  changes  in  quantity. 
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II. M.   Summary  of  Chapter  II 

In  Chapter  II,  we  have  presented  an  overview  of  the  environment 
in  which  the  provisioner  must  work.  We  have  proposed  a  system  to 
support  his  activities,  based  on  LP  and  offering  a  high  degree  of 
interaction  and  automation  of  data-collection.  We  have  discussed  in 
detail  some  methods  of  re-initiating  the  planning  process,  and  the 
final  system  proposed  is  both  transparent  to  changes  in  planning 
cycle  and  capable  of  partially  re-initiating  the  planning  process 
itself. 

In  Chapter  III,  we  will  detail  the  construction  of  a  PPPP  sys- 
tem which  resembles  the  proposed  system  in  many  ways,  but  which  was 
built  within  constraints  imposed  by  Peerless'  situation.  Along  the 
way,  we  develop  ideas  about  the  stability  of  static  solutions  in  this 
particular  dynamic  environment. 

The  actual  situation  at  Peerless  precluded  construction  of 
this  ideal  system.  Compromises  were  required.  The  task  became  one 
of  designing  a  system  which  could  be  run  at  Peerless  and  which  would 
be  as  close  as  possible  to  the  ideal  system.   It  was  believed  that 
such  a  system  could  be  constructed  with  minimum  hardware  availability. 
Chapter  III  describes  the  resources  actually  available  at  Peerless 
and  the  compromises  reached  in  design  of  the  actual  system. 
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Chapter  III 

DESIGN.  CONSTRUCTION  AND  IMPLEMEKTATION  OF 
THE  PEERLESS  PLANNING  SYSTEM 

III. A.   Available  Resources 

In  reality.  Peerless  had  neither  the  large  EDP  installation 
called  for  in  Section  II. D.,  nor  the  personnel  corresponding  to  such 
an  installation.  It  will  be  convenient  to  organize  our  description 
of  resources  which  were  available  into  machine  and  human  categories. 

Machines:   Peerless  had  two  UNIVAC  1050's,  each  of  which  had 
four  tape  drives,  reader,  punch,  and  printer.  While  the  project  was 
in  progress  the  core  storage  sizes  of  these  machines  were  in  flux, 
but  neither  was  ever  larger  than  24,576  bytes  of  storage.   Initially, 
Peerless  also  had  a  UNIVAC  1004,  which  is  a  general  data-conversion 
machine  permitting  translation  between  any  valid  combinations  of 
cards,  magnetic  tape,  paper  tape  and  printed  output.  The  1004  was 
removed  when  one  of  the  105C's  was  augmented  by  a  paper-tape  subsystem. 
In  addition.  Peerless  had  card-handling  equipment  oriented  toward 
UNIVAC  90-column  cards,  including  keypunches,  sorters,  duplicating 
punches,  and  the  like. 

EDP  Personnel:  Peerless  had  an  EDP  organization  consisting  of 
three  departments  (operations,  programming,  research)  reporting  in 
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parallel  to  the  Vice  President  for  Administration;  the  operations 
section  was  the  largest.  The  programming  section  averaged  about  six 
men;  the  research  section  was  in  fact  one  man.   Since  both  1050*s  had 
been  too  small  to  support  meaningful  use  of  FORTRAN  or  COBOL  until 
recently,  the  programming  and  operations  sections  were  familiar  only 
with  PAL,  an  assembly-language  system. 

Non-EDP  Personnel:   Peerless  had  a  major  asset  (for  building  an 
LP-based  planning  system)  in  its  Process  Design  group.   The  group 
varied  in  size  (averaging  around  six)  and  had  responsibility  for  a 
wide  range  of  analytic  activity  (e.g.  calculating  yields,  analyzing 
hog  purchase,  etc.).   Also  this  group  regularly  ran  LP-based  sausage 
formulations.   The  group  had  some  knowledge  of  LP  and  access  to  the 
information  needed  for  constructing  the  LP  model,  but  they  were  or- 
ganizationally independent  of  and  isolated  from  the  provisioners,  which 
reduced  their  effectiveness  somewhat. 
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III.B.   Issues  of  System  Design  Raised  by  Limited  Resources 

Preliminary  estimates  indicated  that  the  LP  model  underlying  the 
planning  model  would  need  about  I5OO  equality  rows  and/or  upper  bounds. 
While  there  existed  a  small-capacity  LP  package  for  the  1050*s,  there 
was  no  real  hope  for  installing  the  LP  on  one  of  Peerless*  machines. 
We  had  to  look  elsewhere  for  a  machine  to  run  the  model. 

We  planned  initially  to  use  a  UNIVAC  110?  located  in  St.  Paul, 
Minnesota,  150  miles  from  Cedarton.   Data  transmission  at  Peerless  was 
to  be  handled  by  a  high-speed  paper- tape  system,  or  by  a  communi- 
cation subsystem  attached  to  one  of  the  1050's.  Assuming  five-level 
code,  1500  columns,  I5OO  rows  and/or  bounds,  and  an  average  of  200 
characters  of  information  about  each  structural  variable  and  bound  row, 
an  ordinary  2400  baud  telephone  line  would  have  permitted  transmission 
of  output  back  to  Peerless  in  less  than  half  an  hour.  We  found,  how- 
ever, that  there  would  be  a  large  expense  associated  with  such  a  communi- 
cation subsystem  and  that  the  high-speed  paper  tape  device  had  been 
removed.  The  alternative  was  a  teletype  35  ASH  for  paper-tape  punch- 
ing; this  would  require  about  ten  hours  to  punch  all  the  output.  Trans- 
mission of  input  to  St.  Paul  was  estimated  to  require  another  two  hours. 

It  would  not  have  been  feasible  to  accept  twelve  hours  of  trans- 
mission time  per  run,  especially  since  the  probability  of  having  to 
make  at  least  two  attempts  per  successful  run  seemed  high.  One  possi- 
ble solution  was  to  transmit  to  St.  Paul  only  changes  in  input  data 
and  to  transmit  back  from  St.  Paul  only  changes  in  solution  values, 
after  stripping  out  all  excess  blanks  and  other  unnecessary  characters. 
Preliminary  estimates  (and  later  experience  with  the  actual  LP  model  as 
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tested  elsewhere)  indicated  that  this  would  reduce  transmission  time 
to  about  one  and  one-half  hours.  This  was  thought  acceptable. 

In  order  to  achieve  this  reduction  in  transmission  time  it  would 
have  been  necessary  to  maintain  data  files  and  file  maintenance  pro- 
grams at  St.  Paul  as  well  as  at  Cedarton.   Starting  with  a  new  input 
file  at  Cedarton,  we  would  have  gone  through  the  following  procedure: 
At  Cedarton:  • 

Using  Old  Input  File  and  New  Input  File,  produce  paper  tape 
containing  changes 

Transmit  change  tape  to  St.  Paul 

At  St.  Paul; 

Receive  change  tape 

Using  change  tape  and  Old  Input  File,  create  New  Input  File 

Run  LP  with  New  Input  File  Producing  New  Output  File 

Using  New  Output  File  and  Old  Output  File,  create  paper  tape 
containing  changes. 

Transmit  change  tape  to  Cedarton 

Rename  New  Files  as  Old 

At  Cedarton: 

Receive  change  tape 

Using  change  tape  and  Old  Output  File,  produce  New  Output  File 

Rename  New  Tapes  as  Old. 

As  can  be  seen,  this  procedure  would  have  required  nearly  complete 
duplication  of  both  information  and  programs  in  two  widely  separated 
locations.  On  reflection,  therefore,  it  seemed  unattractive.  An 
alternative  was  carrying  tapes  to  and  from  St.  Paul  by  air.   The  time 
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involved  for  this  method  would  have  been  about  the  same  as  for  Teletype 
transmission,  but,  if  necessary,  someone  could  have  accompanied  the 
tape,  thus  allowing  a  number  of  possible  tries  at  solution  before 
returning.  Planning  thus  began  for  a  system  with  basic  turn-around 
time  of  one  full  day. 
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III.C»   Issues  Raised  by  Long  Turn-Around  Times 

The  expected  one-day  turn-around  time  for  the  system  imposed  an 
absolute  requirement  that  a  plan  drawn  by  the  system  be  usable  for  two 
days  after  data  input,  if  re-planning  was  to  occur  every  day.  Prices, 
however,  can  change  hourly,  and  this  caused  some  fear  that  no  plan 
drawn  could  ever  implemented.  Much  hangs  on  our  use  of  the  word 
"usable."  Under  the  present  normal  system,  plans  were  drawn  once  a 
week  and  real-time  modifications  made  as  the  week  progressed.   Cer- 
tainly, a  system  which  could  draw  a  "better"  plan  once  a  week  would 
be  "usable"  in  the  context  of  real-time  modifications. 

This  thinking  led  to  a  proposed  method  of  operation:  the  LP  would 
be  run  on  a  basic  weekly  cycle.  The  provisioners  would  meet  over  the 
output  to  make  their  normal  plan  for  the  coming  week.  During  the  week 
of  operation,  the  provisioners  would  have  available  the  by-product 
information  from  the  LP  as  well  as  a  supplementary  report  detailing 
plans  and  achievements,  and  flagging  major  deviations.   (See  the  PLAN  and 
CONTROL  commands  in  Section  II. G.)  The  normal  real-time  adjustments 
would  be  made,  but,  at  some  level  of  discomfort,  the  entire  planning 
process  could  be  invoked  with  one-day  lead  time,  regardless  of  whether 
it  were  early  or  late  in  the  week. 

To  underscore  the  nature  of  the  system  (medium-range  planning)  we 
decided  to  model  a  month's  operations.   This  meant  that  demand  estimates, 
capacities,  and  other  flows  had  to  be  stated  in  terms  of  monthly  rates. 
It  also  meant  that  the  output  of  the  LP  system  would  be  stated  as 
monthly  rates.   Since  the  provisioners  were  used  to  thinking  in  weekly 
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rates,  this  scheme  required  them  to  spend  extra  effort  in  production  of 
data  and  interpretation  of  output,  but  we  thought  that  this  would  be, 
on  balance,  beneficial,  since  it  would  serve  as  a  constant  reminder 
that  the  system  was  primarily  for  planning.  We  were  wrong  —  the  extra 
effort  served  only  to  annoy,  and  we  later  changed  the  model  to  a  weekly 
basis. 

In  Chapter  II  we  assumed  that  changeover  costs  were  absorbed  in 
the  cost  of  planning.   In  fact,  we  were  unable  to  determine  changeover 
costs  for  the  Peerless  manufacturing  operation.  We  were  assured  that 
in  many  cases  these  were  minimal,  since  machines  typically  had  to  be 
cleaned  and  set-up  each  morning  anyway.  Clearly,  however,  a  large  change 
in  the  rate  of  hog-killing  would  cause  costs  to  be  incurred.  We  de- 
cided to  leave  this  to  the  user  of  the  system  by  giving  him  the  aproxi- 
mate  cost  of  not  following  a  new  plan.  He  could  then  decide  whether  or 
not  to  actually  change  production  costs  involved.  This  number  also  pro- 
vides feedback  to  the  user  as  to  how  necessary  re-planning  really  was. 

We  expected  that  initial  use  of  the  planning  system  would  show 
re-planning  much  more  often  than  once  a  week,  but  that  the  proportion 
of  times  when  new  plans  were  implemented  on  the  production  floor  would 
be  relatively  low.  We  also  expected  that,  as  users  became  more  familiar 
with  the  system,  their  demands  for  re-planning  would  fall,  while  the 
proportion  of  implementation  would  rise.  These  expectations  were  based 
on  the  belief  that  humans  are  efficient  pattern-recognizers  and  on  the 
belief  that  profound  changes  in  the  structure  of  a  solution  would  have 
relatively  small  effects  on  the  value  of  the  solution.  The  latter  point 
is  described  in  detail  in  the  next  section. 


56 


III.D.  On   the  Useful  Life  of  a  Plan 

It  is  the  purpose  of  this  section  to  discuss  the  useful  life  of  a 
plan  drawn  from  a  static  model  but  used  in  a  dynamic  environment.   It 
is  useful  to  consider  the  question  in  terms  of  three  major  components 
of  solution  decay.   In  increasing  order  of  relative  importance  (based 
on  this  particular  situation)  these  are:  changes  in  model  coefficients; 
changes  in  quantities:  and  changes  in  prices. 

Changes  in  Model  Coefficients:  The  most  common  source  of  changes 
in  model  coefficients  comes  from  changes  in  the  relative  mix  by  weight 
and  grade  of  hogs  available  for  purchase.   The  hog  mix  is  strongly 
affected  by  such  factors  as  weather,  feed  prices,  and  others  not  under 
Peerless'  control.   It  was  agreed,  however,  that  such  changes  take 
place  slowly  enough  so  that,  by  using  last  week's  experience,  next 
week's  experience  could  be  predicted  very  well. 

Another  source  of  coefficient  changes  comes  from  technological 
changes  in  the  manufacturing  process.   While  these  cannot  be  predicted, 
they  can  certainly  be  detected.   Indeed,  Process  Design's  normal  task 
is  to  calculate  and  monitor  yield  coefficients  throughout  Peerless' 
operations.   For  the  most  part,  such  changes  would  be  expected  to  take 
place  relatively  slowly.   Once  again,  weekly  updating  would  seem  ample. 

Changes  in  Quantities;   Because  of  duality,  what  can  be  said  about 
price  changes  (below)  can  also  be  said  about  quantity  changes.   The  ex- 
ception, of  course,  is  that  while  price  changes  can  move  us  away  from 
optimality,  quantity  changes  can  deny  us  feasibility  as  well.   For  this 
reason,  quantity  changes  may  appear  to  be  more  important  than  they  really 
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are.   Bear  in  mind  that  the  quantities  modeled  in  this  system  are  weekly 
rates.   A  quantity  change  thought  to  be  long-term  (a  new  standing  order 
from  a  chain,  for  example)  probably  justifies  a  re-planning  cycle,  since 
the  problem  caused  by  such  a  change  will  not  go  away  tomorrow.   On  the 
other  hand,  a  short-term  quantity  change  (failure  of  a  carload  of  some 
primal  to  arrive  on  time,  for  example)  does  not  justify  re-planning,  if 
the  carload  will  arrive  tomorrow,  since  no  change  in  the  optimum  rate  of 
use  of  these  primals  is  implied. 

The  planning  system  xd.ll  not,  in  general,  tell  us  what  to  do  today 
in  the  case  of  a  short-term  quantity  change.  We  must  invoke  the  present 
human  procedures  for  such  decisions.   But  the  planning  system  may  well 
provide  better  clues  than  are  now  available  to  the  human  system  as  to 
what  to  do  today.  Whether  to  thaw  frozen  primals  or  to  substitute  a  less- 
preferred  size,  selling  fewer  on  the  open  market,  is  a  question  readily 
answered  from  LP  output,  since  the  cost  of  forcing  additional  units  of 
any  structural  variable  into  solution  is  always  available. 

Moreoever,  many  troublesome  quantity  changes  can  be  treated  as  price 
changes.   That  is,  when  we  say  that  fewer  hams  are  available  today  than 
previously  assumed,  we  may  mean  that  we  will  have  to  raise  our  offering 
price  to  get  more  —  not  that  they  do  not  exist.   (That  the  converse  is 
true  on  the  selling  side  is  obvious.)  Here  again,  the  marginal  return 
figures  are  powerful  guides. 

In  summary,  the  planning  system  can  cope  with  long-term  quantity 
changes  and  can  guide  the  provisioner  in  coping  with  short-term  changes. 
It  remains  to  show  that  the  plans  drawn  by  the  system  can  be  usable  in 
the  face  of  price  changes. 
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Changes  in  Prices:  We  should  begin  be  defining  a  few  terms:   "price" 
will  be  taken  to  mean  the  coefficient  in  the  objective  function  row  cor- 
responding to  a  structural  variable.  We  assume  maximization,  so  the 
price  of  a  bought  quantity  is  negative,  while  the  price  of  a  sold  quan- 
tity is  positive.  We  will  use  the  term  "reduced  cost"  for  what  we  have 
previously  called  "Marginal  Return  for  Increase,"  as  the  net  objective 
function  change  for  one  additional  unit  of  any  structural  variable.  By 
"optimal"  we  mean  computationally  optimal,  i.e.  such  that  the  reduced 
costs  of  all  non-basis  variables  are  non-positive,  except  for  those  at 
upper  bound,  which  must  be  non-negative.  Thus  an  optimal  solution  is 
one  which,  delivered  intact  to  a  simplex  algorithm,  will  not  be  subject 
to  change  of  either  status  or  objective  function  value.  With  reference 
to  a  particular  optimal  solution,  the  "C-range"  of  a  variable  is  the 
range  of  values  over  which,  cet.  par. ,  the  price  of  the  variable  can  be 
varied  without  any  change  in  the  solution  status  of  this  variable  or 
any  other. 

The  reduced  cost  Dj  of  any  non-basis  variable  j  is  (in  a  maximi- 
zation problem)  just  its  actual  price  Cj  less  its  implicit  cost  Zj  which 
is,  of  course,  derived  from  the  prices  of  basis  variables  and  the  active 
substitution  relationships;  or: 

Dj  =  Cj  -  Zj 

The  traditional  term  "reduced  cost"  comes  from  the  fact  that  most 
early  LP  work  involved  minimization.   In  a  maximization  problem,  the 
term  is  misleading,  but  we  retain  it  for  the  sake  of  consistency.  The 
equation  above  states  a  physical  reality:   introducing  one  more  unit  of 
j  into  solution  increases  the  objective  function  by  Cj,  but  drives  out 
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of  solution  some  mix  of  other  variables  which  would  have  yielded  Zj  if 
left  in  solution. 

The  C-range  of  any  non-basis  variable  is  serai-infinite.  For  a  vari- 
able at  lower  bound: 

Dj   -  0;  or 

Cj  -  Zj  -^0;  or 

Cj     ^    Zj 
while  for  a  variable  at  upper  bound: 

Dj      5i    0  or 

Cj   ^  Zj 
The  C-range  of  any  basis  variable  is  determined  by  the  reduced 
costs  of  non-basis  variables.  The  price  of  any  basis  variable  may  be 
allowed  to  vary  only  until  the  variation  causes  some  reduced  cost  to 
become  zero.   In  general,  the  C-range  of  a  basis  variable  is  finite. 

Remember  that,  if  all  prices  in  the  entire  model  were  multiplied 
by  some  constant,  (say  R)  then  the  objective  function  value  would  also 
be  multiplied  by  R,  but  no  change  in  optimality  would  occur.   This 
implies  that  if  all  prices  changed  in  the  same  proportion,  no  change  in 
optimality  would  occur.  Labor  costs  will  not,  however,  change  with 
buying  and  selling  prices. 

Price  Changes  for  a  Single  Variable:  We  can  unambiguously  decide 
whether  or  not  a  single  price  change  will  drive  a  given  optimal  solution 
to  non-optimality.   If,  after  the  price  change,  the  price  is  still  within 
its  C-range,  the  solution  is  still  optimal.   If  the  change  brings  the 
price  outside  the  C-range,  the  solution  is  no  longer  optimal.   But 
the  plan  based  on  the  solution  may  still  be  usable  with  or  without 
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minor  changes. 

For  example,  suppose  we  have  a  large  inventory  of  some  dry  saus- 
age product,  so  we  have  placed  an  upper  bound  of  zero  on  its  manufacture 
in  this  planning  period.  Let  us  also  suppose  that  it  appears  profitable 
so  it  is  driven  to  its  upper  bound  (zero)  and  its  reduced  cost  is  .02 
(2  cents  per  pound).   In  trying  to  unload  the  high  inventory,  the  market- 
ing department  reduces  its  price  by  3  cents.   The  reduced  cost  is  now 
-.01,  which  is  non-optimal  for  a  variable  at  upper  bound.   Operationally, 
however,  there  can  be  no  change,  since  re-optimization  will  simply  drive 
it  to  its  lower  bound  (also  zero)  with  no  change  in  recommended  quanti- 
ties. The  only  changes  will  be  in  the  apparent  C-ranges  of  this  vari- 
able and  of  other  variables  which  are  substitutes  or  ingredients.  These 
changes,  however,  will  be  misleading,  since  the  recommended  quantity 
of  this  product  is  fixed  at  zero.   In  fact,  to  preserve  maximum  solution 
information,  such  variables  (fixed  at  zero)  should  perhaps  be  removed 
from  the  model  temporarily  so  that  all  C-ranges  given  by  the  solution 
will  be  based  on  feasible  substitutions.  The  disadvantage  of  such  sim- 
plification is  that,  while  the  lower  bound  zero  is  a  real  physical  fact, 
the  upper  bound  zero  is  a  tactical  decision  on  the  part  of  the  user. 
By  including  this  variable  in  the  model,  we  give  him  information  about 
the  cost  of  not  manufacturing  this  product. 

The  foregoing  is  a  somewhat  extreme  example,  but  there  are  many 
similar  situations  which  arise  in  practice.   For  example,  consider  a 
rise  in  price  of  .0025  in  a  purchased  primal.  This  may  take  the  price 
outside  its  C-range  by  driving  the  reduced  cost  of  removing  similar 
primals  from  the  freezer  to  a  very  slightly  positive  value.   But 
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suppose  there  are  only  a  few  thousand  pounds  in  the  freezer.  Once  they 
are  gone,  we  will  have  to  return  to  purchased  primals.  The  user  can 
safely  decide  to  use  frozen  primals  briefly  and  then  return  to  purchasing 
without  worrying  about  any  major  disruption  in  the  plan,  even  though  the 
solution  on  which  the  plan  is  based  is  now  technically  non-optimal.  It 
is  still  operationally  optimal,  once  the  frozen  primals  have  been  con- 
sumed. 

What  has  decayed  in  both  the  above  cases  is  the  quality  of  C-range 
information.   In  general,  there  is  no  convenient  way  (short  of  re-running 
the  LP  model)  to  determine  the  new  C-ranges,  though  in  particular  cases 
it  may  be  possible. 

One  other  situation  where  a  single  price  change  can  send  a  solution 
non-optimal  without  destroying  the  plan  comes  about  when  a  relatively 
simple  substitution  is  called  for.   For  example,  in  sausage  manufactur- 
ing, two  different  forms  of  pork  trim  may  have  identical  formulation 
characteristics,  but  different  sources,  prices,  and  availabilities. 
When  their  prices  shift  relative  to  one  another,  the  solution  becomes 
non-optimal,  but  optimality  is  restored  simply  by  substituting  the 
cheaper  for  the  more  expensive.   Once  again,  though,  C-range  information 
is  lost. 

Changes  in  Two  or  More  Prices:  Remembering  the  physical  signifi- 
cance of  C-ranges,  it  is  clear  that  in  the  case  of  non-basis  variables, 
any  number  of  price  shifts  in  the  free  direction  (positive  for  variables 
at  upper  bound,  negative  for  variables  at  lower  bound)  serve  only  to 
widen  the  C-ranges  for  basis  variables,  thus  retaining  optimality  and 
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presumably  enhancing  the  stability  of  the  solution.  Still  for  non-basis 
variables,  any  number  of  price  shifts  toward  the  finite  C-range  limit 
(Zj)  can  be  tolerated,  as  long  as  no  single  C-range  is  exceeded.  The 
solution  remains  optimal,  but  C-ranges  of  basis  variables  are  narrowed. 
This  is  because  the  values  of  Zj  depend  only  on  the  prices  of  basis 
variables,  and  the  C-ranges  of  basis  variables  depend  only  on  the  Dj's. 

But,  if  two  or  more  prices  shift,  and  at  least  one  variable  affected 
is  a  basis  variable,  then  it  is  possible  that  the  solution  becomes  non- 
optimal  even  though  all  prices  are  within  their  C-ranges.  This  follows 
from  our  discussion  of  single  price  changes  because  one  shift  within 
the  C-range  determined  by  the  solution  is  actually  sufficient  to  drive 
the  solution  to  non-optimal ity. 

In  fact,  we  can  state  a  necessary  (but  by  no  means  sufficient)  con- 
dition for  non-optimal ity  given  a  set  of  price  shifts.  Assume  that 
every  variable  K  has  undergone  a  price  shift  S^  (many  of  which  are  zero). 
Now  define  R,  as: 

.     \     =  ac    ,    S^     =     0, 

Rk  =  Uk  -  C^.  S^      ^  0. 

^k  ""  ^k  ■  W'   \    ^  °' 
where  \]^   and  Lj^  are  the  upper  and  lower  limits,  respectively,  of  the 
C-range  for  variable  K,  Cj^  is  the  solution  price  of  variable  K,  and 
Ck  "•"  Sit  i^  ^^^   "®w  price  of  variable  K.  Now  form  the  sum 


B  =  S  ■   1  Sk 
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If  B  '-  1,  the  solution  is  still  optimal.   If  B  -■*  1,  the  solution  may 
be  non-optimal,  and,  in  the  very  special  case  of  only  one  shift,  B  >  1, 
strictly  implies  non-optimality. 

An  Examjple:  Perhaps  we  should  introduce  an  example  which  will  make 

clear  some  of  the  foregoing  discussion. 

Maximize  F  =  .Ix.  +  .2x2  ■*■  '^^'i 
Subject  to:      x-^^  +  2x3  ^30 

x^       +  4xo    -  ^+0 

F  =  6       .  ;  ■  :  ..^  ■  ■ 

x-j^  =  0  (non-basis,  lower  bound)  '    . 
X2  =  15  (basis) 
Xo  =  10  (basis) 

c,  =  .1,  C-range  of  1  =  0  to  .175 

Cp  =  .2,  C-range  of  2  =  .05  to  o^       /  '  -  . 

c^  =  .3.  C-range  of  3  =  0.0  to  00 

After  examining  this  problem,  it  is  clear  that  any  combination  of 
decreases  in  c^   and  increases  in  03  or  03  makes  no  change  in  the  recom- 
mended solution. 

Now  suppose  shifts  arrive  such  that  .   _ 

c-j^  =  .15.    C2  =  .151    Co  =  .3 
so   s-|   =  .05,    S2  =  -.05,   S-.  =  0 


and  %  =  .075,   R2  =  -15.    R3  =  <^ 
Thus,  B  =  .05/. 075  +  -05/. 15  +  0/'^   =  1 
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The  solution  remains  optimal  at  F  =  5-25-  However,  should  c^  rise 
or  c::  fall,  B  would  exceed  1,  and  optimality  would  be  lost. 
Now  suppose  new  shifts  arrive  such  that 

c\   =  .15.   C2  =  .10,   C3  =  .6 


s-j_  =  .05,   S2  =  -.1,   s^  =  .3 


R^  =  .075.  R2  =  -15.   R^=  "^ 


B  =  .05/. 075  +  .I/.I5  +  .3/^  =  1-1/3  ^  1 

But  the  solution  remains  optimal  at  F  =  7-5'  To  restate:  for 
no n- optimality,  it  is  necessary  that  B  —  1,  but  B  -^  1  does  not 
necessarily  imply  non-optimal ity  if  the  number  of  price  shifts  is 
two  or  more. 

Compensating  Shifts:   In  many  cases,  a  set  of  two  or  more  shifts, 
some  or  all  of  which  take  their  prices  beyond  their  C-ranges,  will  still 
leave  the  solution  optimal.   In  fact,  such  sets  of  compensating  shifts 
are  the  rule  rather  than  the  exception.   Bear  in  mind  that  the  two 
limits  of  the  C-range  of  a  basis  variable  are  determined  by  two  reduced 
costs.   It  is  likely  that  the  C-range  of  basis  variable  k  is  determined 
by  the  reduced  costs  of  non-basis  variables  i  ana  j  which  are  nearly 
direct  substitutes  for  k.   Conversely,  the  reduced  costs  of  i  and  j 
are  determined  by  the  prices  of  i,  j,  and  k.  Because  meat-packing  is 
so  nearly  perfectly  competitive,  a  shift  in  the  price  of  k  usually 
implies  corresponding  shifts  in  the  prices  of  i  and  j. 
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In  our  testing,  we  consistently  found  that  the  C-ranges  of  variables 
with  high  price  volatility  (e.g.  purchased  green  hams)  were  determined 
by  the  prices  of  direct  or  indirect  substitutes,  all  of  whose  prices 
could  be  expected  to  change  together.  Rarely  was  the  C-range  of  such  a 
variable  dependent  on  some  price  expected  to  change  independently. 

Essential  Decomposability:  Though  this  will  be  discussed  in 
more  detail  below,  the  nature  of  the  manufacturing  process  at  Peerless, 
and  therefore  the  nature  of  the  LP  model  itself  contributes  to  plan 
stability.   The  model  is  divided  into  sections  corresponding  to  various 
primal  cuts.  These  sub-models  interact  only  at  the  point  of  hog  kill- 
and-cut  and,  to  the  extent  that  their  by-products  are  used,  the  point 
of  sausage  formulation.   A  set  of  price  shifts  which  genuinely  drive 
the  current  solution  non-optimal  in  the  loin  sub-model  will  affect  the 
ham  sub-model  only  if  some  major  change  in  the  rate  of  hog  kill-and-cut 
is  indicated.  This  is  a  relatively  rare  event.  It  occurred  only  once 
in  testing,  when  a  purchase  price  was  inadvertently  omitted,  thus  giv- 
ing the  effect  of  free  purchased  primals.   It  is  therefore  likely  that 
much  of  a  plan  will  remain  usable  even  if  some  part  is  no  longer  optimal. 

Cost  of  Non-Optimality:   It  is  difficult  to  get  a  good  approximation 
to  the  cost  of  not  re-planning  in  the  case  of  a  non-optimal  plan.   In 
the  case  of  a  single  price  change,  a  useful  upper  bound  on  the  differ- 
ence between  status  quo  and  re-optimization  can  be  had  by  multiplying 
the  amount  by  which  the  offending  variable's  price  lies  outside  its 
C-range  times  the  maximum  quantity  change  possible.  The  latter  quan- 
tity may  be  hard  to  determine  unless  the  offending  variable  is  bounded. 
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It  is  available  as  part  of  the  post-optimality  output  of  standard  LP 
codes,  however,  and  we  included  it  in  Section  II. G. 

Another  interesting  scheme  (due  to  J.  F.  Shapiro)  calls  for  observ- 
ing the  dual  objective  function  after  price  change  —  comparing  it 
with  the  normal  objective  function.   (We  avoid  the  word  "primal"  in  this 
context  for  obvious  reasons.)  We  then  know  that  the  new  objective 
function,  after  re-optimization,  will  lie  between  the  normal  and  dual 
objective  functions  before  re-optimization.   Unfortunately,  this  calls 
for  keeping  the  current  basis  inverse  available  for  computing  dual 
variables.   In  our  case,  this  means  a  large  number  of  coefficients 
(roughly  ^4-00, 000)  and  very  substantial  computation  tirrie  on  the  Peerless 
1050 's.  We  did  not  pursue  the  idea  further. 

Summary  of  this  Section:  This  section  has  presented  arguments 
about  the  stability  of  LP-based  plans  in  the  face  of  the  potential 
components  of  solution  decay.  While  no  absolute  conclusions  could  be 
reached  on  the  basis  of  these  arguments,  our  feeling  was  that  the  use- 
ful life  of  plans  drawn  for  Peerless  by  an  LP  system  would  surely  ex- 
ceed the  required  minimum  of  two  days  beyond  data  imput.   The  following 
sections  describe  the  design  and  construction  of  the  LP  model,  LP 
support  system,  and  associated  systems. 
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III.E.   Design  and  Construction  of  the  Peerless  LP  Model 

Scope  and  Nature  of  the  Model:  We  decided  that,  to  be  useful, 
the  model  would  have  to  represent  every  major  controllable  quantity 
in  the  procurement/provisioning/production  sequence.   This  meant  that 
there  would  separate  columns  for: 

Aggregate  Hogs  Purchased 

Hogs  Killed  by  Weight  and  Grade 

Cedarton  Priraals  Produced 

Priraals  Purchased 

Primals  Removed  from  Freezer 

Primals  sold 

Primals  Frozen 

Finished  Products  Produced  from  Primals 

By-products  Produced  in  Kill,  Cut-out,  and  Production 

Allocations  of  Primals  to  Production  Processes 
(by  process,  as  well  as  totals) 

Sausage  Materials  Purchased 

Sausage  Material  Removed  From  Freezer 

Sausage  Material  Sold 

Sausage  Material  Frozen 

Finished  Sausage  Sold 

Allocation  of  Sausage  Material  to  Sausage  Production 

Labor  Utilization  by  Type 

Miscellaneous  Cost  Components 

By  far  the  largest  single  category  of  structural  variables  is 

allocations.  Each  variable  represents  the  allocation  of  some  material 
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to  a  particular  production  process.   In  general,  there  is  one  such 
column  for  each  and  every  way  each  and  every  material  can  be  used.  Nor 
is  there  any  one-to-one  correspondence  with  finished  products.   For  ex- 
ample, boned,  cured  hams  can  be  allocated,  size  by  size,  either  to  smok- 
ing or  to  canning.   If  allocated  to  canning,  each  size  results  (proba- 
bilistically) in  some  mix  of  canning  grades.  Each  canning  grade  may  be 
allocated  to  some  mix  of  canning  splits.  Each  canning  split  results  in 
some  mix  of  canned  hams.   Thus  there  are  an  infinite  number  of  ways  to 
allocate  the  boned  cured  hams  to  canning  in  order  to  meet  finished 
goods  requirements.   These  are  achieved  by  a  two-stage  procedure  of  al- 
locating hams  by  size  to  canning  and  allocating  the  resulting  canning 
grades  to  splits. 

The  second  largest  category  of  variables  is  the  production  of 
finished  goods.   The  scheme  chosen  for  these  was  as  follows: 

Using  a  demand  forecast  (initially  manual,  later  mechanized), 
inventory  information,  and  so  on,  the  marketing  managers  and  product 
managers  determined  the  maximum  and  minimum  allowable  production  over 
the  planning  period.  The  price  attached  to  each  such  variable  was  the 
average  realized  price  for  the  product  discounted  for  the  holding 
period.   For  many  products,  this  scheme  is  equivalent  to  weekly  demand 
at  the  average  sales  price,  but  for  long-lived  products  with  pronounced 
seasonality  (canned  ham,  for  example)  production  may  be  vastly  differ- 
ent from  sales,  and  realized  price  (after  discounting  for  time  and  after 
horse- trading)  may  be  different  from  current  selling  price. 

We  also  decided,  for  the  reasons  mentioned  in  Section  II. C,  to 
standardize  on  a  model  containing  only  equations,  no  inequalities.  This 
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gave  rise  to  the  need  for  a  few  (less  than  100)  structural  variables 
which  served  the  purpose  of  slacks.   This  slight  awkwardness  was  a  small 
price  to  pay  for  a  model  containing  only  one  kind  of  row  and  where  all 
bounds  belonged  to  variables.   In  fact,  by  introducing  two  or  three 
variables  used  as  constants  (upper  and  lower  bounds  equal)  we  were  able 
to  eliminate  all  non-zero  right-hand-side  elements.   This  greatly  sim- 
plified the  design  of  the  support  system  described  in  Section  III.G. 

Although  the  standard  UNIVAC  110?  LP  code  was  not  written  for  the 
bounded-variable  algorithm,  we  continued  to  design  the  model  as  if  it 
had  been.  We  hoped  that  such  a  code  would  become  available  for  the 
1107/1108  or  that  an  existing  FORTRAN  IV  code  could  be  adapted  for  the 
1107.   If  neither  were  true,  however,  the  LP  support  system  could 
easily  have  been  modified  to  insert  phony  rows  wherever  bounds  were 
needed  and  then  to  bring  the  output  information  back  to  the  columns 
after  a  run.   The  only  problem  would  have  been  with  the  capacity  of 
the  1107  code,  then  2047  rows.  This  was  later  raised  to  4095  rows, 
which  would  have  been  more  than  sufficient  for  our  purposes. 

Construction  and  Testing  of  the  Model:  The  LP  model  was  constructed 
and  tested  in  sections.   The  purpose  was  to  simplify  de-bugging  and  to 
allow  the  constructors  to  concentrate  on  one  area  at  a  time.  Sections 
constructed  were,  in  chronological  order: 

Hog  purchase,  kill,  and  cut 

Hams 

Bellies 

Picnics  . 
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Loins,  Butts,  Ribs,  and  Miscellany 
Sausage  manufacture 

We  chose  to  model  a  particular  month,  January  196?,  because  we  had 
reasonably  complete  information  as  to  what  had  in  fact  been  done  at 
Cedarton  over  that  period.   Changing  to  another  month  would  then  require 
only  changes  in  technological  yield  coefficients,  hog  mix,  primal  prices, 
and  demanded  quantities,  all  of  which  could  be  entered  through  the  LP 
support  system,  to  be  described  later. 

Testing  was  carried  out  on  an  IBM  l620  computer  at  the  Sloan  School. 
The  LP  package  for  this  machine  has  a  capacity  of  ^+00  rows  and  3000  col- 
umns, and  uses  the  bounded-value  algorithm.  Its  output,  especially  of 
post-optimality  information,  is  not  extensive.   Its  input  format,  however, 
is  compatible  with  LP  packages  available  for  the  UNIVAC  IIO7/IIO8: 
IBM  7040,  7044,  709,  7090.  7094,  S/36O;  and  others.   It  is  very  slow. 

Details  of  the  form  of  the  model  are  left  to  the  appendix  to  this 
chapter,  but  it  may  be  profitable  here  to  sketch  the  construction  and 
testing  process  itself. 

Process-Flow  Charts:   The  first  step  in  model  construction  was  a 
set  of  process-flow  charts,  which  traced  the  flow  of  each  material  (e.g. 
a  particular  size  of  a  particular  primal)  through  all  the  possible 
steps  of  production,  including  the  production  of  by-products.  These 
were  helpful  in  determining  the  mathematical  formulation  required.   As 
an  example,  consider  an  imaginary  primal,  the  15-17  lb.  Widget. 

With  reference  to  Exhibit  II,  note  that  a  dot  indicates  either  a 
choice  among  alternative  uses  of  a  product  or  a  summation  of  alternative 
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Exhibit  II 
Process-Flow  Chart  For  15-17  lb*  Widgets 
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Exhibit  II  (continued) 
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sources;  in  either  case,  a  row  is  required  in  the  model.  A  box  represents 
an  identifiable  quantity,  and  will  appear  as  a  column  in  the  model. 
The  number  of  columns  in  the  final  model  will  be  at  most  the  count  of 
all  unique  boxes  on  all  charts.   For  example,  SO'Jo  Lean  Widget  Trim  will 
appear  on  several  charts.   These  will  all  be  represented  by  at  most  a 
single  column,  summed  up  in  a  summation  row.   If  all  80%  Lean  Widget 
Trim  ends  up  as  a  sausage  material,  there  may  be  no  explicit  column  for 
it.   Instead,  there  will  be  columns  for  each  possible  allocation  of  it 
to  sausage  formulation.  An  inverted  T  structure  on  the  chart  represents 
a  process  producing  two  or  more  products  in  fixed  proportions.  Thus 
15-17  Widgets  To  Production  yields  both  S>0%   Lean  Widget  Trim  and  12-14 
cured  and  trimmed  widgets.  Note  that  two  dots  separated  only  by  a 
line  either  collapse  into  a  single  row  or  require  a  box  between  them. 

Tableaux:  Each  process-flow  chart  was  then  translated  into  a 
tableau.  With  the  exception  that  all  rows  are  equations  with  zero 
right-hand  sides,  these  were  perfectly  standard  LP  tableaux. 

Coding  Forms:   The  numbers  on  each  tableau  were  then  transferred 
to  coding  forms  and  keypunched  onto  cards  —  one  coefficient  per  card, 
identified  by  column  ahd  row  numbers. 

Editing:  The  cards  were  then  run  through  an  editing  program 
which  performed  certain  simple  validity  checks  on  the  data  and  trans- 
formed row  and  column  identification  into  a  form  acceptable  to  the  1620 
LP  package.   The  resulting  cards  were  then  combined  with  the  cards  de- 
fining that  part  of  the  model  already  tested  to  produce  a  new  more  com- 
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plete  model  ready  for  testing. 

The  LP  Data-Manipulation  Package:  Since  the  model  was  stored  as 
a  card  deck,  deletions,  insertions,  and  other  similar  operations  were 
simple  manual  procedures.   However,  there  were  a  large  number  of  other 
manipulations  which  were  found  to  be  needed  time  and  time  again,  and 
a  set  of  1620  programs  was  developed  to  handle  them.  These  programs 
became  prototypes  of  some  of  the  parts  of  the  LP  support  system  described 
later,  but,  since  they  were  written  assuming  a  large  random-access 
capability  of  the  l620,  they  were  not  transferable  to  Peerless'  1050's. 
This  package  had  the  following  capabilities: 

1.  Sort  by  column  and  row  numbers  —  required  to  meet  the 
necessity  of  having  all  data  for  a  single  column  con- 
tiguous in  the  input  stream. 

2.  List  model  in  column  order  —  gives  a  complete  image  of 
the  current  model.  This  is  useful  for  de-bugging  purposes. 

3.  List  model  in  row  order  —  gives  a  complete  image  of  the 
current  model.  This  is  also  useful  for  de-bugging  purposes, 
especially  when  trying  to  correct  infeasibility. 

k.      Flag  infeasible  rows  —  since  all  rows  are  equations  with 

zero  right-hand-sides,  any  row  which  does  not  have  at  least 
one  positive  coefficient  and  at  least  one  negative  coefficient 
is  likely  to  cause  an  infeasibility. 

5-   Flag  superfluous  columns  —  a  column  with  one  coefficient 
is  probably  a  mispunching  error.   One  exception  is  a  column 
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used  as  a  slack. 

6.   Reduce  matrix  —  in  this  particular  model,  many  rows  have 
only  two  coefficients,  meaning  that  some  column  is  a  fixed 
multiple  of  some  other  column.  The  prime  example  is  in  the 
hog  purchase,  kill,  and  cut  section,  where  each  live  weight 
column  is  a  fixed  fraction  of  the  number  of  hogs  killed.   By 
using  this  capability,  108  columns  and  108  rows  can  be  elimi- 
nated from  the  model  for  testing  purposes.  When  this  is 
done,  it  is  seen  that  each  Cedarton  primal  column  is  a  fixed 
fraction  of  the  number  of  hogs  killed.  35  "Jore  such  rows 
and  columns  can  be  eliminated.  This  is  very  important  be- 
cause  solution  times  tend  to  vary  as  something  more  than  N  , 
where  N  is  the  number  of  rows.   After  testing  is  done,  the 
original  form  must  be  restored,  because  there  may  be  valuable 
information  in  the  shadow  prices  of  the  eliminated  rows. 

?.   Selective  deletion  —  allows  deleting  coefficients  by  in- 
dividual coefficient,  whole  column,  or  class  of  columns. 

8,   Selective  bound  changes  —  allows  one  to  vary  the  range  of 
upper  and  lower  bounds  on  a  class  of  columns.   This  was 
useful  in  exploring  the  profit  to  be  had  by  moving  from 
what  was  done  toward  the  LP  recommendations.  This  would  not 
have  been  needed  had  the  1620  LP  package  been  capable  of 
parametric  programming. 

With  the  help  of  this  data  manipulation  package,  we  were  able  to 
test  the  entire  model  without  sausage.  This  subset  had  329  rows 
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(after  reducing  the  matrix)  and  required  about  14  hours  of  1620  time 
to  optimize  from  an  all-logical  basis.  Construction  and  testing  of 
the  model  went  on  in  parallel,  and  together  took  about  six  months.  The 
next  section  details  the  results  of  our  testing. 
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in.F.  Results  of  Model  Testing 

This  section  describes  the  results  obtained  in  testing  the  Peer- 
less LP  model.  As  has  been  mentioned,  such  testing  was,  initially, 
performed  incrementally.  Not  until  late  in  the  project  was  the  en- 
tire model  tested  at  once.  However,  the  entire  model  except  for  sausage 
and  with  a  simplified  kill-and-cut  section  was  tested  over  a  period  of 
of  nearly  two  months.   This  somewhat  reduced  model  had  roughly  1000 
columns  and  330  rows,  and  totalled  4000  coefficients. 

Caution  is  indicated  in  interpreting  these  results.  These  re- 
sults are  at  best  impressions,  because  no  truly  uncontaminated  results 
were  produced.  We  were  never  really  certain  until  later  testing  stages 
that  the  model  was  free  of  errors,  and  rarely  was  a  run  made  which  did 
not  include,  besides  deliberate  changes  in  prices,  quantities,  and 
structure,  some  changes  needed  to  correct  errors  observed  in  the  pre- 
vious run  or  runs.   Thus,  a  great  deal  of  interpretation  was  needed 
in  order  to  separate  the  effects  of  such  changes.   Nevertheless,  we 
did  have  the  opportunity  to  become  almost  intimately  familiar  with  the 
working  of  this  particular  model  in  the  face  of  many  different  kinds 
of  changes.   Our  observations  follow: 

Price  changes  in  a  single  primal  section  rarely  changed  the 
solution  status  of  any  variables  in  any  other  section.  The  apparent 
decomposability  of  the  model  was  upheld,  in  that  changes  within  a  single 
primal  section  were  unable  to  affect  other  sections.   This  is  because 
the  major  interactions  are  at  the  hog  kill-and-cut  section,  and  it 
apparently  takes  a  substantial  change  in  the  price  of  any  class  of 
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primals  to  change  the  status  of  the  kill-and-cut  solution. 

Re-solution  in  the  face  of  price  and  quantity  changes  was 
normally  quick.  Re-solution  of  the  entire  model  after  price  and  quan- 
tity changes  was  performed  approximately  30  times,  h   of  which  repre- 
sented across-the-board  changes.   In  only  one  case  did  a  re-solution, 
using  as  an  initial  basis  the  optimal  basis  for  the  previous  solution, 
require  more  than  N  iterations,  where  N  is  the  number  of  rows.  We 
must  qualify  this  statement  somewhat:  Whenever  the  new  model  was  in- 
feasible,  the  determination  of  this  fact  often  took  2N  to  3N  iterations. 
In  fact,  it  became  so  clear  that  long  solution  times  were  associated 
with  infeasibility  that  we  considered  cutting  off  solutions  still  in- 
feasible  after  N  iterations  so  as  to  conserve  computer  time.  We 
abandoned  this  idea  because  knowing  the  point  at  ;riiich  infeasibility 
actually  occurs  in  solution  is  an  extremely  powerful  tool  for  diagnos- 
ing the  problem. 

Profit  Potential  was  large.   In  an  experiment  conducted  on  ham 
splits  alone,  we  observed  considerable  pay-off  from  following  the  LP 
recommendations.  The  procedure  was  as  follows.   Production  of  finished 
canned  hams  was  bounded  to  t  5%   of  actual.  Allocation  of  primal  hams 
to  splits  was  bounded  to  the  best  approximation  (actual  figures  not 
being  known  or  retrievable)  of  actual  allocations.  This  model  proved 
infeasible.   Bounds  on  allocation  to  splits  were  then  opened  up  to 
^  2056  of  estimated  actual  and  the  model  run.   This  showed  a  profit 
figure  slightly  higher  than  actual  for  ham  canning  in  that  month. 
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Then  bounds  on  splits  were  removed  altogether.  The  objective  function 
showed  an  increase  of  approximately  $230,000  for  the  month. 

Structural  changes  (beyond  minor  ad.justments  to  coefficients)  were 
costly.   Addition  of  rows  or  columns  to  the  model,  and  especially  the 
addition  of  whole  sections,  typically  caused  considerable  complication 
in  re-solution.  In  addition,  such  activity  obviously  increases  the 
probability  of  infeasible  or  unbounded  solutions,  all  of  which  contrib- 
utes to  wasting  of  time. 
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III.G.   Design  and  Construction  of  the  LP  Support  System 

The  LP  support  system  was  designed  to  give  the  users  as  many 
features  of  the  "ideal"  system  of  Chapter  II  as  could  be  achieved  on 
a  small  tape-oriented  computer,  given  the  necessity  of  carrying  tapes 
back  and  forth  between  the  "home"  computer  and  the  large  machine 
required  for  the  LP.  Three  major  features  had  to  be  sacrificed  en- 
tirely, though  partial  compensation,  was  possible.   (Other  features, 
recognized  as  worthy  but  not  absolutely  essential  for  operation,  were 
deferred  and,  as  a  result,  never  implemented.)  The  three  lost  features 
were : 

1)  On-line  editing  and  modification  of  coefficients; 

2)  On-line  calls  for  special  reports;  and 

3)  Monitoring  by  partial  solution. 

In  our  view,  the  most  serious  loss  was  the  third.  All  question 
as  to  whether  or  not  a  solution  remains  optimal  in  the  face  of  multi- 
ple price  changes  becomes  unimportant  if  the  LP  code  itself  is  avail- 
able for  monitoring.  The  process  is  simplicity  itself:  using  the  old 
basis  inverse  and  the  new  set  of  prices,  perform  one  matrix  multipli- 
cation to  determine  the  new  set  of  reduced  costs.   If  these  are  all 
non-positive  (except  for  variables  at  upper  bound  which  must  be  non- 
negative)  then  the  solution  remains  optimal.   Since  the  basis  inverse 
really  specifies  a  set  of  row  transformations  sufficient  to  change  the 
initial  simplex  tableau  into  the  final  (optimal)  tableau,  it  matters 
very  little  whether  the  inverse  is  kept  in  terms  of  the  actual  inverse 
(around  400,000  numbers),  product  form  (usually  many  fewer  numbers),  or 
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just  as  a  list  of  variables  and  their  solution  status  together  with 
the  original  tableau  (least  of  all  because  of  the  sparseness  of  the  . 
original  matrix).   In  any  of  these  cases,  the  time  required  to  re- 
calculate the  reduced  costs  is  on  the  order  of  a  minute  or  two  on  the 
class  of  machine  needed  to  support  the  LP  code  itself.   However,  on  a 
UNIVAC  1050  with  24K  core  and  no  random-access  mass  storage,  this 
task  becomes  huge. 

The  appendix  to  this  chapter  contains  a  detailed  description  of 
the  support  system  as  it  existed  in  December  1967-   In  this  section 
we  describe  the  design  of  the  system  in  broad  terms  only.   It  is  ap- 
propriate to  begin  with  the  most  important  artifact  of  the  system. 

The  LP  Master  File:   The  LP  Master  File  is  a  single  reel  of  tape 

containing  all  information  required  to  run  and/or  interpret  two 

different  versions  of  the  model.  We  will  call  these  two  models  the 

current  or  A-model  and  the  new  or  B-model.  Both  models  are  on  the 

same  tape  for  reasons  of  simple  data-handling  ease.  The  file  is  in 

column  order,  and  for  each  column  contains: 

Column  Coefficients  for  A-model 

Alphabetic  description  of  column 

Solution  information  for  this  column  of  A-model 

Column  coefficients  for  B-model 

Alphabetic  description  of  column 

Solution  information  for  this  column  of  B-model 

Let  us  consider  the  use  of  the  Master  File  throughout  the  planning 

cycle.   Suppose  we  have  just  implemented  a  plan  based  on  the  most 

recent  solution  of  the  LP.   At  this  point  (take  it  on  faith)  the  A- 

model  and  the  B-model  are  identical.  We  now  consider  functions  of  the 
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support  system,  given  this  initial  situation. 

Modify  Prices  and/or  Bounds :  A  new  set  of  prices  and  bounds  are 
prepared  and  punched  on  cards.   These  cards  are  used  to  update  the 
coefficients  in  the  B-section  of  the  file.  The  A-section  now  contains 
coefficients  and  solution  information  corresponding  to  the  most  recent 
run  of  the  LP,  ^ile  the  B-section  contains  coefficients  for  the 
next  run  of  the  LP.   B-model  solution  information  is  now  meaningless. 

Modify  Model  Structure:  The  same  as  above,  except  that  coeffi- 
cients other  than  prices  and  bounds  may  be  changed,  and  whole  columns 
and/or  rows  may  be  added  or  deleted.   These  two  functions,  which  are 
handled  by  the  same  program,  are  the  equivalent  of  MODSTRUCTURE  (and 
EDSTATUS)  of  Chapter  II. 

Monitor  Changes :  A  report  is  drawn  showing  the  net  difference 

between  the  coefficients  in  the  A-model  and  the  B-model.  That  is, 

every  coefficient  which  is  either: 

Different  in  B  from  value  in  A;  or 
Present  in  B  but  not  in  A;  or 
Not  present  in  B  but  present  in  A 

is  written  out  in  a  report  giving  before-and-after  values. 

Monitor  Prices:   Every  column  whose  B-price  is  outside  its  C-range 
as  defined  by  the  A-solution  is  noted  on  a  report,  together  with  full 
information  from  both  models. 

List  Model:   The  complete  B-model  is  listed  in  column  and/or 
row  order. 


83 


Draw  Input  Tape :  The  B-raodel  is  transformed  into  a  tape  suitable 
for  use  as  input  to  the  LP  package. 

Optimize:   Not  a  part  of  the  support  system,  this  step  consists 
of  carrying  the  LP  input  tape  as  prepared  above,  the  optimal  basis  (on 
cards)  from  the  last  run,  and  any  changes  deemed  necessary  by  the  user, 
to  the  machine  on  which  the  LP  code  is  resident.  The  output  is  a  new 
optimal  basis  deck,  an  LP  output  tape,  and  printed  reports. 

Update  B-Solution:  The  LP  output  tape  is  used  to  update  the 
B-solution  in  the  Master  File.   The  Master  File  now  contains  the  most 
recently  implemented  model  (A-model)  and  the  most  recent  unimplemented 
model  (B-raodel).  Solution  information  for  each  model  corresponds  to 
its  coefficient  information  and  includes  the  quantities  called  for  in 
Chapter  II. 

Report:  The  entire  B-solution,  together  with  Alphabetic  descrip- 
tions, is  written  in  a  report  suitable  for  use  by  the  provisioners  and 
product  managers. 

Report  Solution  Changes:   The  entire  Master  File  is  scanned,  and 

whenever  the  B-solution  differs  in  any  way  from  the  A-solution,  both 

are  written  out.   By  means  of  this  function,  the  user  can  judge  how 

profound  the  changes  in  solution  actually  were.   In  addition,  this 

report  contains  the  three  objective  function  values  mentioned  in  Chapter 

II,  namely: 

A-model  objective  function; 

B-model  objective  function;  and 

A-B  objective  function  (A-quantities  at  B-prices) 
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Accept  Solution:  This  routine  (actually  the  same  as  the  Report 
Solution  Changes  routine)  produces  a  new  Master  File  whose  A-section 
has  been  replaced  by  the  B-section;  that  is,  the  B-tnodel  is  declared 
to  be  current. 

Dump  Model:   The  entire  B-section,  including  coefficients,  descrip- 
tions, and  solution  information  is  dumped  in  a  single  report  to  the 
major  user.  This  gives  him  a  superior  ability  to  trace  out  any  unusual 
result.   In  fact,  this  is  the  same  routine  v«riiich  is  used  to  create  a 
listing  of  the  model  in  column  order.   The  difference  is  in  the  timing; 
the  column  list  comes  before  the  solution,  the  dump  afterwards. 

This  completes  the  description  of  the  main  parts  of  the  LP  support 
system.   In  addition,  there  are  two  routines  designed  to  prevent  errors. 

Monitor  Inconsistencies:  Every  alphabetic  description  begins  with 
a  single  character  giving  the  class  of  variable  (e.g.  B  for  buy,  S  for 
s_ell,  A  for  allocate,  etc.).  This  routine  checks  every  column  descrip- 
tion against  its  new  (B-model)  price  and  flags  inconsistencies  such  as 
a  positive  price  for  a  bought  quantity. 

Manipulate  Prices:  Designed  to  prevent  errors  by  reducing  the 
task  of  data  input,  this  routine  accepts  a  table  of  relationships  be- 
tween one  master  price  (say  the  Chicago  market  for  a  primal)  and  many 
dependent  prices  (cost  of  purchase,  return  from  sale  of  the  same  primal 
at  Cedarton).  It  then  accepts  master  prices  and  punches  change  cards 
to  correspond. 
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Implementation  of  Variable  Planning  Interval  Through  Human 
Decisions :  There  are  obviously  two  decision  points  in  the  replanning 
process.  The  first  comes  in  deciding  whether  or  not  to  re-plan.  This 
decision  is  made  by  the  provisioners  using  system  functions  already 
described.  Remember  that  the  B-model  has  the  cumulative  changes  in 
coefficients  since  the  A-model  was  run.  At  any  time,  the  provisioners 
can  invoke  the  Monitor  Prices  routine  to  get  a  list  of  all  columns 
whose  prices  fall  outside  their  C-ranges.   The  provisioners  must  still 
decide  whether  or  not  to  re-plan.   They  will  be  aided  by  the  report  from 
the  Monitor  Changes  routine.   For  instance,  if  there  are  a  large  number 
of  columns  appearing  on  the  Monitor  Prices  report,  but  the  Monitor 
Changes  report  shows  them  all  to  be  proportional  changes  in  the  prices 
of  various  versions  of  one  single  primal,  the  odds  are  good  that  the 
current  solution  in  fact  remains  optimal. 

It  is  also  true  that,  at  any  time,  the  provisioners  can  invoke 
the  Draw  Input  Tape  routine  to  initiate  the  remote  procedure  for  ob- 
taining an  LP  solution.  Having  done  so,  and  having  obtained  an  LP 
Output  Tape  and  run  Update  B-solution,  the  provisioner  is  faced  with 
deciding  whether  or  not  to  accept  (implement)  the  new  solution.  To 
aid  in  this  procedure,  he  has  three  documents:  the  LP  report  as  pro- 
duced by  the  LP  code  itself;  the  LP  report  produced  by  the  Report 
routine;  and  the  change  report  produced  by  the  Report  Solution  Changes 
routine.  He  must  judge  whether  the  return  from  changeover  to  the  new 
plan  justifies  its  costs.  These  reports,  and  (later  on)  his  experi- 
ence in  previous  decisions  of  the  same  sort,  should  allow  him  to  make 
good  decisions  on  the  question  of  acceptance. 
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Construction  of  the  System:  The  system  was  constructed  as  a  set 
of  modules,  some  of  which  were  programmed  by  UNIVAC  personnel,  the 
rest  by  Peerless.   The  major  modules  were: 

1)  Create  sorted  change  tape.   Cards  are  accepted  in  a  variety 
of  formats,  converted  to  a  single  consistent  format,  and  sorted  into 
column-row  order  for  updating  the  Master  File.   One  problem  arose  here 
—  the  sort,  a  standard  merge  procedure,  would  not  necessarily  preserve 
the  order  of  tied  entries.   As  a  result,  no  duplicate  column- row  com- 
bination could  be  tolerated  in  a  single  batch  of  change  cards.   This 
meant  that  change  cards  from  two  separate  days  (or,  for  that  matter, 
hours)  could  not  be  batched  together.   A  manual  procedure  for  pulling 
duplicates  was  instituted  temporarily,  but  the  long-term  solution  was 
to  append  the  serial  position  of  each  card  in  a  batch  to  the  sort  key 
before  sorting. 

2)  Update  B-model.  A  sorted  change  tape  is  passed  against  a 
Master  File,  and  a  new  Master  File  created  whose  B-model  embodies  the 
changes  specified.   As  above,  no  duplicate  changes  were  tolerated  in 
the  first  version;  later  versions  were  to  ignore  all  but  the  last  such 
duplicate. 

3)  Extract  Extended  Master  File.  The  Extended  Master  File,  con- 
sisting of  complete  B-model  information  in  an  easy-to-process  form,  is 
extracted  from  the  Master  File.  This  is  used  by  several  other  modules 
(see  below),  and,  as  a  bonus,  is  in  the  same  format  as  a  sorted  change 
tape,  so  that  it  can  be  used  to  create  a  whole  new  B-model  if  necessary. 

4)  Produce  LP  Input  File.   The  Extended  Master  File  is  passed  and 
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a  tape  acceptable  to  the  remote  LP  code  is  written.  This  program  was 
to  exist  in  three  versions: 

a)  Produce  full  input  tape  for  110?  code.   Each  coefficient 
becomes  a  card  image  in  110?  format.   Each  column  bound  becomes 

a  new  row  and  a  coefficient  card  image  and  a  right-hand-side 
element  card  image. 

b)  Produce  change  tape  for  110?  code.   As  above,  but, 
by  comparing  against  Master  File  A-model,  program  suppresses 
card  images  which  have  not  changed  since  last  run. 

c)  Produce  full  input  tape  for  360  code.  As  a)  above, 
but  bounds  do  not  become  new  rows;  rather,  they  are  held  in  one 
special  row  acceptable  as  input  to  the  360  LP  code. 

5)  Compare  coefficients.   A  comparison  is  made  between  the 
Master  File  A-model  and  the  Extended  Master  File  (drawn,  of  course, 
from  the  3-model).   Depending  on  the  setting  of  a  switch,  this  com- 
parison results  in  either: 

a)  Report  of  changed  coefficients;  or 

b)  Report  of  prices  outside  their  C-ranges. 

6)  Check  inconsistencies.   Performs  the  function  called  "Moni- 
tor Inconsistencies"  above,  using  the  Extended  Master  File  as  input. 

7)  Produce  row  list.   The  Extended  Master  File  is  sorted  in 
row-column  order  and  printed. 

8)  Dump  Master  File.  The  B-model  of  the  Master  File  is  printed 
verbatim.   This  is  used  both  as  a  column  listing  of  the  model  and  as 
a  model  dump  after  updating. 
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9)  Update  B-solution  and  report.  The  LP  Output  Tape  is  scanned 
and  information  collected  by  column.  This  collected  information  is 
then  inserted  into  the  B-solution  area  of  the  Master  File.   Each 
updated  B-solution  line  is  printed.   Because  of  the  format  of  the 
Master  File,  these  printed  lines  become  the  Peerless  LP  report.  There 
were  to  be  two  versions  of  this  routine: 

a)  Process  110?  output.   This  version  would  have  to  asso- 
ciate four  pieces  of  information  with  each  column: 

i)  Column  solution  information 

ii)  Row  solution  information  for  special  rows  created 
as  bounds 

iii)  Post-optimality  information  by  column 

iv)  as  iii)  for  rows. 

b)  Process  36O  output.  As  a)  but  types  ii)  and  iv)  not 
required  because  of  use  of  bounded  variable  algorithm. 

Modularity  could  have  been  enhanced  here  by  separating  the  ex- 
tractor of  information  from  the  LP  Output  Tape  from  the  Master  File 
update  and  printing  functions.  We  overlooked  this  opportunity. 

10)  Print  Changes.  Described  above  as  "Print  Solution  Change 
Report." 

In  addition  to  the  major  modules  described  above,  several 
others  had  been  designed  and  partially  programmed  by  December,  1967- 
These  were: 

11)  Extract  price  information  from  PYRAMIDS. 

12)  Produce  control  report  from  PYRAMIDS. 

13)  Manipulate  prices. 

14)  Produce  special  reports  (table-driven). 
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III.H.   Testing  of  the  LP  Support  System  and  Parallel  Operation  of 
the  Planning  System. 

Testing  of  the  LP  support  system  and  first  use  of  the  planning 
system  were  carried  out  together,  because  it  was  felt  that  there  could 
be  no  better  test  of  the  support  system  than  coping  with  an  actual 
model  in  a  closely  simulated  planning  context.  Accordingly,  the  cards 
defining  the  model  as  tested  in  Cambridge  were  shipped  to  Cedarton 
and  testing  of  the  whole  system  began,  even  though  the  system  was  far 
from  complete.  "■■ 

At  the  outset  we  had  one  stroke  of  good  luck.  A  36O/5O  with  128K 
bytes  of  core  was  found  in  Cedarton  itself.   The  company  leasing  the 
machine  (call  it  the  Nonpareil  Company)  had  already  brought  the  36O  LP 
code,  MPS/360,  to  fully  usable  status  and  was  willing  to  let  Peerless 
use  several  hours  per  month  on  very  reasonable  terms.  The  availability 
of  MPS/360  significantly  reduced  the  programming  required  for  many  of 
the  modules  described  in  Section  III..G.  More  important,  the  "remote" 
machine  was  now  only  20  minute's  drive  from  Peerless.  The  tape-carrying 
procedure  required  by  the  system  began  to  look  more  and  more  feasible. 

One  complication  arose.   The  Peerless  equipment  used  90-column 
cards  and  7-track  tapes,  while  the  Nonpareil  equipment  used  80-column 
cards  and  9-track  tapes.  This  problem  was  resolved  when  Peerless 
agreed  to  subsidize  Nonpareil  to  the  extend  of  one  7-track  tape  unit, 
and,  in  addition,  installed  one  IBM  Keypunch  on  the  Peerless  premises. 

Another  minor  problem  was  the  difference  in  character  codes  between 
the  UNIVAC  and  IBM  equipment.  This  was  handled  by  substituting  a 
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non-standard  conversion  table  for  the  normal  one  built  into  UNIVAC 
software.   In  short,  data  transmission  problems  were  solved  reasonably 
quickly. 


Operatinp,  procedure  at  Nonpareil:   The  operating  procedure  at 
Nonpareil  became  a  well-established  routine: 

1)  Mount  LP  Input  File  on  7-track  drive. 

2)  Run  MPS  CONVERT  routine  to  convert  LP  problem  to 
internal  format  on  a  new  tape  file  PROBFILE. 

3)  Run  MODIFY  routine  to  enter  any  changes  to  model 
(usually  errors  detected  and  punched  after  the 
preparation  of  the  LP  Input  File). 

4)  Run  SETUP  routine  to  prepare  to  solve. 

5)  Run  INSERT  routine  to  insert  optimal  basis  from 
last  run. 

6)  Run  PRIMAL  routine  to  solve. 

7)  Run  SOLUTION  routine  to  write  solution  information 
on  LP  Output  Tape. 

8a)   (If  infeasible)  Run  TRACE  routine  for  diagnostic 
information;  or 

8b)   (If  unbounded)  Skip  to  9;  or 

8c)   (If  feasible-optimal)  Run  RANGE  routine  for  C-ranges,  etc. 

9)  Run  COBOL  program  (written  for  the  purpose)  to  print  LP 
Output  Tape  and  copy  the  relevant  subset  onto  the  7-track 
drive  (where  a  blank  tape  should  have  been  mounted  during 
PRIMAL)  for  carrying  back  to  Peerless. 

10)  Examine  output.   If  infeasible,  unbounded,  or  unreasonable, 
correct  errors  and  return  to  step  3>   Otherwise,  go  home. 

It  should  be  noted  that  all  the  above  steps  (except  for  numbers  1) 

and  10)  are  performed  automatically  via  the  MPS/360  control  language 

and  the  OS/360  Job  Control  Language. 
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In  early  runs,  the  vrtiole  procedure  required  an  average  of  three 
or  more  tries  on  the  machine,  2  hours  of  360/5O  time,  and  10  hours 
of  effort  by  each  of  two  or  three  men.   By  December,  196?,  error 
detection  and  correction  and  general  knowledge  of  the  model  had  pro- 
gressed so  that  a  typical  Nonpareil  run  required  one  or  two  tries, 
a  total  of  45  minutes  of  computer  time,  and  perhaps  6  man-hours  of  . 
effort. 

The  timing  figures  given  are  for  the  complete  model  which  was 
in  flux  throughout  the  testing  period,  but  which  averaged  700  rows 
and  2100  columns.  Some  of  the  problems  encountered  in  debugging  the 
whole  system  were: 

1)  Infeasibility :  because  of  the  model  structure,  infeasi- 
bility  was  usually  the  result  of  errors  in  the  change  cards.  Because 
of  the  structure  of  MPS/36O,  such  errors  were  easy  to  trace.   But 
each  occurrence  forced  additional  delay. 

2)  Unbounded  Solutions:  change  card  errors  were  again  respon- 
sible for  most  unbounded  solutions.   However,  MPS  (or  at  least  the 
version  we  used)  had  no  facility  for  revealing  which  variable  was  being 
brought  into  solution  at  the  time  unboundedness  was  detected.   Our 
first  cut  at  ameliorating  this  problem  was  to  modify  the  "Prepare  LP 
Input  Tape"  procedure  to  supply  a  large  upper  bound  for  all  variables 
without  natural  upper  bounds.   Then  any  unbounded  solutions  were  easily 
traced  after  optimality.   Our  second  approach  also  involved  a  modification 
to  "Prepare  LP  Input  Tape."  MPS  permits  the  definition  of  a  new  row 

as  the  linear  combination  of  any  two  other  rows.  We  defined  such  a 
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row  to  be  identical  to  the  objective  function,  but  to  be  less-than 
constraint  with  a  right-hand-side  value  roughly  four  times  the  largest 
expected  objective  function  value.  Thus,  when  an  unbounded  solution 
occurred,  the  next  variable  entered  into  solution  raised  the  extra 
row  to  its  cnaximura  value  and,  there  being  no  further  way  to  increase 
the  objective  function,  the  simplex  procedure  terminated.  The  trace 
of  iterations  leading  to  solution  would  then  have,  as  its  last  entry, 
the  identification  of  the  unbounded  variable.   The  advantage  of  this 
method  over  the  first  is  that  it  would  typically  waste  less  time.  That 
is,  the  detection  of  an  unbounded  solution  terminated  the  simplex 
procedure. 

3)  Huge  volume  of  data  input:   Our  preliminary  estimates  were 
that,  on  average,  200  to  500  prices  and  bounds  would  change  between 
runs.   In  face,  running  on  a  weekly  cycle  (with  the  option  of  running 
sooner  if  required),  we  found  that  700  to  1200  numbers  had  to  be 
input  for  each  run.   The  first  reason  is  the  fact  that,  as  in  model 
testing  described  in  III.F. ,  many  errors  had  to  be  corrected  with  each 
run.  Moreover  sausage  sections  were  continually  being  added  to  the 
model  as  testing  went  on.   But  the  major  cause  of  excess  data  input 
was  that  the  product  managers  found  it  easier  (or  at  least  safer)  to 
send  in,  as_  changes,   every  price  and  bound  under  their  control,  whether 
actually  changed  or  not.  This  put  a  heavy  load  on  the  time  and  patience 
of  everyone  concerned  in  the  input  process,  not  least  the  product 
managers  themselves.  The  long-term  solution,  of  course,  was  to  use 
the  PYRAlflDS  file  as  a  data  source,  thus  eliminating  almost  all 
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manual  input.   In  the  short  run,  however,  we  designed  a  set  of  computer- 
prepared  input  forms,  so  that  the  product  managers  could  see  what  the 
old  value  of  each  price  or  bound  was  as  they  were  writing  in  new 
values.  This  was  expected  to  reduce  changes  to  tne  originally  esti- 
mated level,  but  there  were  enough  technical  problems  in  producing 
such  input  forms  so  that  this  feature  was  never  fully  implemented. 

k)     Consistently  incorrect  coefficients:  System  testing  uncovered 
what  was  apparently  a  long-standing  disagreement  between  the  "official" 
cut-out  yields  and  the  yields  used  by  provisioning  to  predict  primal 
production.  The  "official"  yields  were  re-worked  and  entered  into  the 
model  four  times,  but  the  model  was  never  able  to  be  even  qualitatively 
as  accurate  as  the  provisioners'  estimates.  There  was  a  carefully  con- 
trolled test  in  which  the  "official"  yields  operated  upon  actual  hog 
kill  experience  for  a  week,  and  even  then  there  was  only  fair  agreement 
between  actual  production  and  model  predictions.   The  "official"  yields 
were  being  reworked  for  the  fifth  time  when  work  on  the  project  was 
suspended. 

There  were  many  other  problems  —  human,  hardware,  and  software  — 
but  the  four  above  were  the  major  obstacles.   There  were  also  several 
benefits,  but  the  outstanding  gain  came  from  the  involvement  of  Peerless 
personnel  in  the  model-building  and  error  tracing  processes.  The 
Process  Design  group  was  the  greatest  beneficiary,  but,  as  each  new  run 
was  examined  and  criticized,  even  the  provisioners  and  product  managers 
gained  insight  into  the  hog-to-final-product  process.   There  is  some 
evidence  that  this  effect,  at  least,  will  De  a  long-term  help  to 
Peerless. 
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III.  J.   The  End  of  the  Pro.iect 

Financial  difficulties  forced  Peerless  to  cancel  all  projects 
"not  now  fully  implemented"  in  December,  196? •   The  LP-based  planning 
system  fell  into  this  category  and  was  accordingly  "suspended  indefi- 
nitely." But,  as  always,  the  classification  of  the  planning  system 
as  "not  now  fully  implemented"  was  a  human  decision  —  in  this  case, 
a  decision  of  the  Chief  Provisioner.   His  stated  reason  was  that,  given 
Peerless'  very  tight  cash  position,  he  did  not  have  enough  maneuvering 
room  to  exploit  the  LP  recommendations,  even  if  he  could  rely  on  them 
—  and  the  fact  that  the  very  important  yield  coefficients  were  in 
their  fifth  re-work  was  evidence  enough  that  he  could  not  rely  on  the 
LP. 

There  were  several  contributing  factors  of  which  two  should  be 
cited: 

First,  the  long  turn-around,  high  error  rate,  and  inability  to  get 
good  predictions  of  primal  production  (all  of  which  we  emphasize,  were 
improving  rapidly  with  time)  had  allowed  the  provisioners  to  avoid  con- 
fronting the  question  of  just  how  much  help  the  system  could  be  as  a 
planning  aid.   They  were  therefore  uncommitted. 

Second,  parallel  operation  of  two  systems  is  a  meaningless  exer- 
cise when  the  users  have  never  really  had  enough  time  to  keep  the 
old  system  running  smoothly.   This  was  very  nearly  the  case  at  Peerless. 
The  additional  time  required  to  run  the  new  system  in  parallel  was  a 
far  more  burdensome  cost  than  the  additional  money. 

Indeed,  the  only  way  that  all  the  problems  could  have  been  solved 
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would  have  been  for  the  provisioners  to  take  responsibility  for  the 
accuracy  of  data  input  and  the  smooth  operation  of  the  support  system. 
However,  there  is  a  clear  tendency  for  people  to  prefer  responsibility 
for  an  overall  (human-generated)  plan  to  responsibility  for  the  num- 
bers on  wnich  a  (machine-generated)  plan  is  based.   Some  of  the  reasons 
are  obvious.  First,  human  plans  have  the  characteristic  that  errors 
tend  to  be  proportional  to  mistakes,  vriiile  a  machine-generated  plan 
has  the  potential  for  a  very  small  mistake  (in  input  data)  to  produce 
profound  errors  in  the  plan.   Second,  in  this  particular  complex  plan- 
ning scheme,  it  is  hard  to  predict  what  effect  on  the  plan  will  be 
caused  by  a  relatively  minor  decision  about  prices,  bounds,  and  the 
like.   It  may  be  that  this  planning  system  gave  the  provisioners  too  much 
responsibility. 

Shortly  after  the  planning  system  was  suspended,  the  provisioners 
evolved  a  scheme  which  has  some  of  the  potential  of  the  LP  system  and 
many  fewer  problems.   Starting  with  each  primal,  manual  calculations 
are  made  of  the  potential  profit  for  each  possible  way  of  allocating 
that  primal  to  production.   These  profit  figures  are  then  used  in 
making  allocation  decisions.   Such  a  scheme,  while  it  does  not  take 
account  of  interactions  and  is  therefore  surely  suboptimal,  will  be 
we  hope,  at  least  livable,  and  certainly  better  than  what  existed  before 
the  LP-based  planning  system  was  initiated. 
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Appendix  to  Chapter  III 

The  purpose  of  this  appendix  is  to  describe  the  LP  model  and 
support  system  as  they  existed  in  December  196?. 

A»  Model  Description 

The  general  LP  problem,  cast  into  a  form  consistent  vrith  our 
model  formulation  is : 


Maximize     Z 

J^l 

Cj^j 

Subject  to: 

^  aijXj 

=  0; 

i  = 

J=l. 


where  Xj  is  the  value  of  the  j   variable  or  quantity  to  be  determined 
(e.g.,  pounds  of  a  primal  to  be  bought);   C^  is  the  price  of  variable  j; 
a^  -;  is  the  coefficient  in  column  j  and  row  i;  L-?  is  a  lower  bound  for 
variable  j;  U^  is  an  upper  bound  for  variable  j.  There  are  N  variables 
or  columns  and  M  rows  or  equations. 

An  LP  solution  is  feasible  when  the  values  of  the  Xj's  satisfy  all 
N  equations  and  fall  within  their  respective  bounds.   An  LP  solution 
is  optimal  when  there  exists  no  feasible  change  in  the  values  of  the 
X-j's  which  increases  the  value  of  Z.  When  a  solution  becomes  optimal, 
each  variable  has  associated  with  it  a  level  or  recommended  quantity 
and  a  C-range  or  range  over  which,  cat,  par.  The  price  of  this  vari- 
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able  may  vary  without  loss  of  optimality.   The  level  and  the  C-range 
are  the  two  most  important  elements  of  the  plan  arawn  for  each  variable. 

The  actual  model  (see  Figure  3)  is  divided  into  ten  logical 
units: 

1.  Kill:   one  variable  representing  total  hogs  purchased  is 
divided  up  into  108  quantities  of  "live  weight"  of  different 
kinds  of  hog.   The  model  is  also  given  the  opportunity  to 
purchase  one  pound  of  each  kind  of  hog  separately.   This  section 
requires  approximately  220  columns  and  110  rows. 

2.  Cut-out:  108  types  of  hog  are  converted  to  35  types  of 
primal.  Labor  costs  are  assessed  and  by-products  accounted  for. 
This  section  requires  approximately  100  columns  and  40  rows. 

3-  Hams:  cut-out  primal  hams  are  summed  with  purchased  and 
thawed  hams  to  give  total  ham  availability.  This  is  distributed 
between  sales,  freezing,  and  production.  Hams  to  production  are 
allocated  to  smoking  and/or  canning.  Each  ham  is  allocated  to  a 
particular  process  ending  in  one  or  more  finished  products. 
Labor  costs  and  by-products  are  accounted  for.  This  section 
requires  approximately  300  columns  and  170  rows. 

4.  Bellies 

5.  Picnics 

6.  Loins 

7.  Butts 
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8.  Ribs:  These  sections  are  somewhat  less  complex  than  hams, 
but  the  same  general  formulations  are  used.  These  sections 
total  approximately  300  columns  and  160  rows. 

9.  Sausage:  This  section  serves  as  a  sink  for  by-products  pro- 
duced in  all  other  sections.  Because  each  material  is  at  least 
potentially  usable  in  every  sausage,  each  separate  kind  of 
sausage  requires  approximately  50  columns  and  10  rows,  for  a 
total  of  1000  columns  and  200  rows. 

10.  Cost  and  Profit:  This  section  merely  sums  up  various 
labor  costs  and  facility  usage  data  for  management  use.  It 
requires  only  about  10  extra  rows  and  10  extra  columns. 

Figure '3  accurately  shows  the  relationship  between  these  sections; 
e.g.,  it  is  true  that  hams  and  bellies  interact  only  at  the  points  of 
cut-out,  sausage,  and  cost  and  profit;  and  it  is  true  that  all  sections 
feed  the  sausage  section. 

B.  LP  Support  System 

The  LP  support  system  is  adequately  described  in  Chapter  III 
itself.  Here,  we  present  a  gross  data-flow  diagram  (Figure  4).   The 
following  section  contains  sample  printed  reports  produced  by  the 
support  system. 
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Figure  4,   continued 
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C.  Sample  System  Artifacts 


1.   Sample  Dump  of  the  B-Section  of  the  LP  Kaster  File 


CLOSES  3*1   0115  ■   -1. 
Sl3  a  35-UP  other  Gr  5K  HAM 

0926       .8031 
BS     27.001 

i05l 

« 

CL052S  B  0   0421     -1. 
CL052&  B'O   0706      0.1 

0701      0.1 
0707      0.1 

0702 
0708 

CL0526  3  0   1002      0.0278 
CL0525  3  1   1059      0.0018 
S3  A   2-25-DWN  C  CaN  GrSKHM 

1050      0.086 
1060      0.0071 
BS    132.089 

1051 
1502 

CL0527  B  1   0122     -1. 

S:j.  a  2  25-UP  OTHEK_GgSKDHAM_ 

CL0529  B  '0   0101     -1,' 
CL0529  B  1   1052      0.131 

0926  '         .7291 
BS     21.B55 

0701      1. 
1053      0,012 

1051 

« 

1001 
1051 

S;^  A  3-12  C'  CAN  GR  Sk  HAM 

ClG530  3  0   0102     -1. 
CL0530  B  0   1050      0.066 
CL0530  3  1   1060      0.0071 
53  A  12-11  C  CAN  GR  SK  HAM 

LL       * 

0701  '     .1600 
I05l      0.089 
1502  99999. 

LL 

•08612- 

0702 
1052 

.03193- 

CL053i  3  0   0103   '   -1, 
CL0531  3  0   1051      0;089 

0703      0.51 
1052      0.131 

0701 
1053 

CL0531  3  1   1502  99999. 

53  A  11-165  C  CAN  qR    SK  HAM 

LL 

.03555- 

CL0532  3  0   0105     -1. 
CL0532  B  0   1050  '    0.066 
CL0532  3  1   1060  '    0.0071 
SB  A  16-lBS  C  CAN  gR  5k  HAM 

CL0533  3  0   0107     -1. 
CL0533  B  0   1051      0.089 
CL0553  B  1   1502  99999. 
SB  A  18-20S  C  CAN  qR    Sk  HAM 

0701      0.22 

1051  0.089 
1502  99999, 

BS    531.362 

0706     0.66 

1052  0.131 

LL 

0705 
1052 

• 

0707 
1053 

.00856- 

CL0531  B  0   0109     -1. 
CL0531  3  0   1050      0.066 

0707      0.13 
105l      0.089 

0708 
1052 

CL0531  3  1   1060      U.0071 
S3  A  20-22S  C  CAN  G^  SK  HAM 

CL0535  B  0   0111     -1. 
CL0535  3  0   1051      0.089 
CL0535  3  1   1502  99999. 

1502  99999. 
BS    511.001 

0709       ."7700 
1052      0.131 

• 

0710 
1053 

53  A  22-2"+  C  CAN  GR  SK  HAM 

CL0536  3  0   0101     -1, 
CL0536  3  0   1052      0.1178 
CL053S  3  1   1502  99999. 
S3  A  3-12  HT  CAN  GR  SK  HAM 

BS     71.280 

0723      0.1 
1053      0.0161 

LL 

• 

1001 
1051 

.11192- 

Cl0537  3  0   0102     -1. 
CL0537  3  0   1002      0.0287 
CL0537  3  1   1059      0,0016 
SB  A  12-11  HT  CAN  gR  Sk  HAM 

0723      0.25 
1050      0.066 
1060      0.0061 
BS     67.361 

0721 
1051 
1061 

* 
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Cl0^33    B    0      0103  -1,  0726  0.2"   "  o727 


.0798         1052                .1121 
.01000-      CL'0522          LL 

'    1502 

.c 

99999. 
)2i+9i+ CLO: 

0.1 
0.1 

3301 

i52      l:l_ 

0705 

1001 

~105t+ 

NONE 

.667 

.100 
0.1 

0703 
0709 
1052 

9-      CL032; 

0.1 
0.1 

0701+ 
0710 

0.1 
0.0026 

0.139 

99999. 

,0721- 

0.132 
5          UL 

1053             0.06 
INFINITY 

0.1005 

.1621         1052                .1025 
.34'+52-      CL0366           LL 

1502    99999, 
INFINITY 

3301 
NONE 

.667 

0.0026 

o.otiia 

1002 
1059 

0.0373 
0.0018 

1050 
1060 

0.066 
0.0071 

l051             0.089 
1502   99999. 

0.61 

0703 

0.23 

1001 

0.0026 
0.0412 

1002 

0.0278 

0.131 

1053 

0.01+2 

1051+ 

1059 

0.0018 

0.1+6 
0.0'I2 

1001 
105i+ 

0.0026 
0.0'+12 

1002 
1059 

0.0278 
0.0016 

1050 
1060 

0.066 
0.0071 

c 

0.56 
0.131 

0706 

1053 

0.22 
0.0^+2 

1001 
1051+ 

0.0026 
0.01+12 

10183        CL02 

0.0278 
0.0018 

1002 
1059 

0.0278 
0.0018 

,00066-      CL07if2          LL 
0.31+             1001              0.0026 

.G 

100  2 
1059 

152          LL 

1050 
1060 

0.066 

O.Ot+2 

1051* 

0.0^+12 

0.0071 

0.1+6 
0.131 

0709 
1053 

0.11 
O.Ot+2 

1001 
1051+ 

0.0026 
0.0'+12 

1002 
1059 

0.0278 
0.0013 

,01138-      CL031] 

L           UL 

.0 

1002 
1059 

11081+        CL03 

il2           LL 

1050 
1060 

• 

0.23 
0.0^+2 

1001 
1051+ 

0.0026 
0.01+12 

0.0278 
0.0018 

10423        CL03 

0.066 

0.066 
0.0071 

.0055C 
0.0023 

)-      CL0360          LL 

1002             0.0287 
1059             0.0016 

.0 

1050 
1060 

.13           LL 
1051 

0.089 

.0511+ 

0.0064 

1061+ 

.0290 

0.15 
0.089 

0725 

1052 
"1502    999C 
L-      CL195] 

0.35 
0.11+78 

0726 
1053 

0.25 
0.01+61+ 

1001 
1054 

0.0023 
.0514 

.0290 
.001+0] 

)9. 

I           UL 

.00137        CL0352           LL 
~0729             0.22             1001 

0.28 

072B 

0.3 

0.0023 

105 
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2.   Sai[5)le  Listing  of  Change  Cards  Submitted  to  "Update  Coefficients" 


CI  RP^fSR.W?.?'^.! 

1 

CL82^6RW8860 
CL82A7RW3.SOO 

-1 
-99 

1 
-1 

.99 

■  CL82^7RW8ltA7 
CL82A7RWn{ 60 

CL82<:taRWl  !jOO 
CL8248RWa048 

-0 

1 

.0720 

CL82A8RWB860 
CL8248RW1?01 

-1 
25 

CL8249RW1 500 
CL8249RW8049 

-0 

1 

.1324 

CL8249RW8860 
CL8249RW1501 

-1 
24 

CL8250RW1500 
CL8250RW8050 

-99 

1 

.99 

CL8250RW8860 
CL8252RW1500 

-1 
-99, 

.99 

CL8252RW8052 

CL825PRWR860 

1 
-1, 

CL8254RW1^00 
CL8254RW8054 

-99, 
1, 

.99 

CL8254RW8860 
CL8256RW1500 

-1. 
-99, 

.99 

CL8256RW6002 
CL8256RW8860 

1. 

-1, 

CL82£>7RwlbO0 
CL8257RW6003 

-99, 
1, 

99 

CL8258Rl;1500 
CL8258RWL058 

-99, 

1. 

99 

CL8258RW8860 
CL8259RW]  I'-OO 

-1. 
-99. 

99 

CL8259RWL059 
CL8259RW8860 

1. 
-1. 

CL8260RW1500 
CL8260RW8060 

-0. 
1. 

32 

CL8260RW8r.60 

CL8260RWlb01 

-1. 
1. 

CL8261RW1300 
CL8261RW8860 

-99. 
-1. 

99 

CL8265RW1500 
CL8265RW8061 

-0. 
1. 

37 

CL8265RW8065 
CL8265RWBH60 

•  1. 
-1. 

CL8265RW1;  01 

45. 
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3.      Saii5>le  Output  of  the   "Monitor  Changes"  Routine 

(Note:      this  sample  taken  prior  to  installation  of  the 
"Monitor  Price"  feature.) 


COEFFICIENT    CHA\3£    LIST  10-20-67 


ROlv 

'AZ'-' 

OL^. 

0063 

O.TS?- 

1500 

1503 

-.1555 

-.169C\ 

.  0  0  ?  = 

u055 

0  OS-l- 
oo 6'4 

1500 

1503 

.0095 
-.1537 

:\0-ME 

.0100 
-.155? 

.0033 

0  0  5  '4 

00  55 
u0  55 

oO^O 
1500 
I5O3 

.0093 
-.1537 

.0110 
-.1552 

.oo^p, 

0055 
u0  65 

0  0  56 

1503 
X503 

.0093 
-.1537 

\'C';\iE 

.0110 
-.155?? 

.00-3 

0  0o5 
0057 

0  0  57 

5oao 

i5uO 
I5O3 

,0093 
-.1537 

.0110 
-.1552 

.003^ 

uO&7 
0063 
•J  OSS 

onao 
1500 
i  5  ■J  3 

.0093 
-.1537 

\'OME 

.0110 

-.1652 

.005S 

00o3 
0059 

O0  69 

1500 

15  0  3 

.0  093 
-.1537 

A"  ONE 

.011 0 
-.1552 

.0030 

0  i"i  6  -3 
0  0  70 
U0  70 

1500 
J.  5  0  3 

.0093 
-.1713 

MO\'E 

.0110 

-.1702 

.010  5 

uO/0 
0071 
0071 

00^0 
0.500 
1503 

.0109 
-.1718 

.  0 1 1 0 

-.1702 

.0105 

0071 

0  072 

0  075 

ori^o 
1500 
1503 

.ul09 
-.1718 

•■iOME 

.Oil  0 
-.1702 

.0105 

U072 
0  0  73 
0  0  7  3 

150c 

15U3 

.0109 
-.1713 

MOVE 

.0110 

-.1702 

.  C  1  0  5 

0073 
007'+ 

oOiiO 
1500 

.0109 
-.1713 

.0110 
-.1702 

4.   Sample  Model  by  Row  Listing 
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4b06 
4600 

(i  i!-:   n  f  f 

42lli 
4250 

.Hi'.ai 

^2n?i 

4600 

4C00 

-1. 

4601 
4601 
4601 

4218 
4250 

.0271 

.ogas 

4601 

4b0l 

-1. 

4602 
4602 
ti6n? 

4216 
42'iO 

.0861 
.0936 

4602 
4602 

4252 
4b02 

.1240 
-1. 

4603 
4603 

4250 

.0620 

,0620 

4605 

4603 

-1. 

4604 
4604 

4252 

4604 

.3262 
-1. 

4605 

4252 
4hn5 

•  .0613 
-1. 

uf>np, 

u?s? 

.12  J  6 

4606 

4t.a6 

-1. 

\ 

4607 
4607 

4351 

4607- 

.05bti5 
-1. 

460B  4350 
4J2.0A_  ItiiOJi. 

.05143 
-1. 
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5.  Sample  MPS  Control  Program 


CONTROL  PROGRAM  COMPILER 
00  0  1  PROGRAM 


0002 

I  NI  TI  ALZ 

00S7 

XFREQINV  =  50 

0058 

XINVFRT  -  1 

0059 

MVAr)R(XnONFS,  INFFAS) 

0060 

MVAOR (XDOUNB, MERTES) 

0061 

MOVE  (XPRNAN'E,"PRF  ILE"  ) 

0062  MOVF( XOLDNAME,  »POFILE'  ) 

0063  MOVE ( XDAT A, "NEWLP")      ^ 
_0 P_6 4 PFVI  SF(  *SUMM ARY  '  ) 


0  0  65  SFTUP(  "nOUNO",'»ZZZZ2ZZZ","MAX") 

0066  MOVE (XOBJ  ,  'RWISOO  •  ) 

_0  0  6  7 MOVF(  XRHS  t"ZZZ  70001  ") 


0068 

MOVF ( XDAT A, 'BAS IS • ) 

0069 

* 

BASIS  INSERT  DLCCK  (PRESENT 

IF  OLD  BASIS) 

0070 

I NSFRT 

0071 

GOTO( DOIT) 

0072 

* 

END  BASIS  INSERT  BLOCK 

0  0  73 

CRASH 

0074 

DOIT 

PRI MAL 

0075 

SOLUTION 

0076 

PUNCH ( »LI ST • ♦ 'VALUE' ) 

0077  RANGE 

0078  EXIT 

0079  INFEAS    TRACE 


OOPO           MERTES     STATUS 
OOei  SOLUTION 

_0 0_82 P U NCH  (  'LIST'  ,  'VALUE'  ) 


0083  EXIT 

0084  PEND 
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6.      Portion  of  Sanple   Iteration  Log 


exECurnrj . 


ITER 

NUMBER 

VECTOR 

VECTOR 

REriUCED 

FUNCTION 

NUMBER 

NONOPT 

OUT 

IN 

COST 

VALUE 

1  17 

1363 

1360 

.05646- 

2215. 1 1 

1  18 

1516 

1252 

.00004- 

2215.33 

M 

I  1<3 

35 

1728 

1663 

. 03923- 

2217.28 

M 

120 

37 

12  52 

1207 

.01636- 

2217.50 

121 

1727 

1544 

.00235- 

221 7.50 

M 

122 

1  1 

1485 

14  85 

.00001 

221 7.93 

123 

1207 

876 

.00001- 

221 8. 13 

124 

782 

171  1 

.00775- 

2218.16 

125 

1656 

1652 

.00313- 

2218.17 

M 

126 

10 

1714 

1210 

.00426- 

2218. 19 

M 

127 

6  ' 

11  86 

1186 

.00000 

221 6.42 

128 

11  85 

1  1  85 

.00000 

2218.65 

129 

1412 

14  94 

.00000- 

2218.78 

130 

1573 

15  74 

.01 032- 

2218.80 

131 

906 

74  6 

. 00000- 

2218.81 

M 

132 

3 

1680 

1681 

.00041  - 

2218.81 

133 

746 

759 

. 00000- 

221 8.82 

134 

1652 

1656 

.001 10- 

2218.82 

M 

135 

5 

759 

771 

.00364- 

2218.84 

136 

1650 

1651 

.00041  - 

22 18.84 

OPTIMAL 

SOLUTION 
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7,      Sajyle  MPS  Output   (columns   section) 
EXECUTOR  . 


^L^'CEfi         .CCLU^N 


AT 


«.  .ACT IVITY. 


INPUT     COST. 


LCUER     LIVIT. 


1222 

CL27C6 

ES 

4C  .COCCC 

1223 

CL27C7 

LL 

40C.0CCC0 

.25400 

400 

.00000 

1224 

CL2708 

LU 

40.00CCO 

.  27880 

40 

.  00000 

1225 
1226 

CL27C9 

LL 

6C  .00000 

.29000 

6C 

. 00000 

CL2720 

ES 

56^.69414 

1227 

CL  272  1 

ES 

E17.C6£Pe   , 

A 

i^2n 

CLr722 

LL 

•* 

1229 

CL2723 

es 

22  1.  leccc 

A 

1230 

CL2724 

LL 

• 

A 

122  1 
1232 

CL2725 

LL 

• 

CL2726 

ES 

132-95600 

A 

1233 

CL2727 

LL 

• 

A 

1234 

CU272a 

LL 

• 

A 

1235 

CL272g 

LL 

•                                       * 

1236 

CL273C 

ES 

35.  12572 

1237 

CL2731 

ES 

143.48227 

1238 

CL2732 

ES 

67.32000 

A 

1230 

CL2733 

LL 

•                                       4 

A 

1240 

CL2734 

LL 

• 

1241 

CL2735 

ES 

137.24C00 

A 

1242 

CL2736 

LL 

•                         a 

A 

1243 

CL2737 

LL 

•                                       4 

1244 

CL273e 

ES 

66.32400 

1245 

CL2739 

ES 

i32.e4eco 

►            .t 

A 

1246 

CL2740 

LL 

« 

A 

1247 

CL274  1 

LL 

•                                                  4 

1248 

CL2742 

ES 

44,21(00 

124  9 

CL2743 

ES 

E23.920CC 

A 

1250 

CL2744 

LL 

•                                                  4 

125  1 

CL2750 

UL 

4C.CCC00 

.  68000 

20, 

.  00000 

1252 
1253 

CL27S1 

UL 

ec.cocoo 

.56000 

40. 

.  00000 

CL2752 

UL 

8C.CCCCC 

.63000 

40. 

,00000 

1254 

CL2753 

EQ 

•                                                  4 

1255 

CL2754 

UL 

120C.00CCC 

.53000 

600 

, 00000 

1256 

CL2755 

UL 

200.00000 

.  eecoo 

100. 

,00000 

1257 

CL275e 

UL 

12C.00C0C 

.52000 

60. 

,  00000 

1258 

CL2757 

UL 

16C.CC000 

,  52000 

80. 

.  00000 

1259 

CL275a 

UL 

ec  .cccco 

,48000 

40. 

.  00000 

1260 

CL2759 

UL 

12C.0C0CC 

.53000 

60. 

,00000 

126  1 

CL2760 

UL 

60.00000 

.  47CCC 

20. 

.00000 

1262 

CL276  I 

UL 

12C.O00O0 

,  46C0C 

60, 

.00000 

12  63 

CL2762 

EO 

4C.CCCC0 

.  46000 

40. 

,00000 

1264 

CL27€2 

EQ 

480.00000 

.41 000 

480. 

00000 

1265 

CL2764 

EG 

40C.CCCC0 

,26000 

400. 

00000 

1266 

CL2850 

ES 

19  p.  2  2  ^€2 

,  C6750 

1267 

CL2e5  1 

es 

62 .  lee  47 

27C00 

1268 

CL2e52 

ES 

32.0  12  10 

.  CI  950 

1269 

CL2e53 

ES 

241.EIP0C 

.27000 

1270 

CL2eS4 

LL 

•                                            4 

,  15000 

1271 

CL3000 

ES 

72.61469 

1272 

CL300  1 

es 

1157.46^95 
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PACE 


39   -   67/312 


UPPFR  LIVTT.    .RECUCED  COST. 


g<3qQ<5, 00000 

600.00000 
120.00000 
120.00000 

.02  1  1€-                     ' 

.0043?- 

.06127- 

99q<3<3. 00000              . 
gogoq, 00000 
99qcic).  00000 

■•          . 

99999.00000              « 
9Q999. 00000 
99999.00000 

99990. 00000 
99999.00000 
99999.00000 

99999,00000               , 
99999.00000              4 
99999.00000 

99999.00000              . 

99999.00000 

qqgqq, 00000 

99999.00000              t 

99999.00000 

99999.00000 

99999.00000 
99999.00000 
99999.00000 

99999.00000 
99999.00000 
99999.00000 

99999.00000 
40.00000 
80.00000 

.  155a  1 

.  10S47 

80.00000 

• 

1200.00000 

.00077 

.46691- 

.09804 

200.00000 
120.00000 
160.00000 

.09906 
.0971 0 
.  10386 

80.00000 

120.00000 

60.00000 

.04571 
.  15766 
.  1007? 

120.00000 

40.00000 

400.00000 

.10538 
.  1  1 243 
.04239 

400.00000 
99999.00000 
99999.00000 

.00  36  6 

Qqqqq. 00000 
99999.00000 
99999.00000 

.01141- 

99999.00000 
99999.00000 

• 
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8.      Sample  Output   (ranges   section) 
EX  ECUTOR  • 


^L' .*«££« 

.ccLu^'^« 

AT 

.../»CT  IVITY... 

..INPUT     COST.. 

.  .  LCUER     LI  MT. 
..UPPER     LI  MI  T, 

12  14 

CL26Ee 

LL 

« 

• 

• 

99998.94830 

1216 

CL27CC 

LL 

3S  .<3?^?4 

.  <ieccc 

19.99997 
39.9999B 

1217         CL27C1  LL 


29CCC 


39. 99999 


1218   CL2702      LL 


i9?.9cse; 


.233A0 


199.99983 
399.99981 


1219        CL27C3  LL 


1  199  .9990  1 


3334C 


1  1 99.99901 
1599.99877 


1220        CL27C4  LL 


19^.95963 


32340 


1 99.99983 
399.99981 


1221   CL27C5      LL 


99998.94830 


1223   CL27C7      LL 


199.99^62 


.25400 


399.99982 
599.99981 


1224   CL27Ce      LL 


39.99999 


27e£C 


39.99999 
1  19.99998 


1225   CL27C9      LL 


5S.99S94 


29000 


59.99994 
1  19.99993 


1228   CL2722      LL 


99998.94830 


1230        CL2724  LL 


99998.94830 


1231         CL2725  LL 


99998.94830 


1233        CL2727  LL 


99998. 94830 


1234        CL272ti  LL 


99998.  94830 


1235   CL2729      LL 


99998.94830 


1239   CL2733     LL 


99998. 94830 
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PACE 


124   -   67/312 


LCWER  ACTIVITY    ...UNIT 
UPPER  ACTIVITY    ...UNIT 


COST..    ..UPPrR  COST..   LIVITIKG   AT 
COST..    ..Lnv.FR  COST..    PRHCFSS.    AT 


ei7.065iq- 

•                           • 

INFINI  "TV- 

• 

CL2721 

CL2659 

LL 
LL 

34. 5^343 
123.4qa58 

13563- 

13563 

.32437 
TNFTNI TY 

CL2251 
CL2251 

LL 
UL 

lO. 70951 

06463 
06463- 

INF  IN  I TV- 
.35463 

CL265C 

CL2600 

LL 
LL 

45f?, 41723- 
730.10356 

00400 
00400- 

INF  INI  TY- 
.33740 

CL2256 
rL?7?0 

LL 
LL 

541.58247 
2204.46788  ' 

00400 

00  40  0-   ^ 

INTINITY- 
.33740 

CL2256 
CL2256 

LL 

UL 

164.24483 
346,05260 

0040C 
004  0  0- 

INFINITY- 
.3374  0 

CL2730 
CL2731 

LL 
LL 

1«3.78C)78- 
3<?. 99997 

INFINITY- 

• 

rL2fi02 
CL2706 

LL 
LL 

448.80744- 
496.76113 

.021  1€ 
021 16- 

INFINITY- 
.27516 

CL2657 
CL2603 

LL 

LL 

59.78978 

,00433 
,00  43  3- 

INFINltY- 
.28313 

CL2706 

CL2602 

LL 
LL 

55.20400 
133.93223 

.06127 
.06127- 

INFINI TY- 
.35127 

a_2251 
CL2251 

LL 
LL 

35.12570- 
143.48219 

INFINITY- 

CL2  73  0 
CL2731 

LL 
LL 

569.89365- 
231.1598R 

INF INITY- 

• 

rL272  0 
CU2723 

LL 
LL 

35.  12570- 
14  3.48219 

INFINI TY- 

• 

CL2  73  0 
CL2731 

LL 
LL 

569.89365- 
133.95591 

INFINITY- 

*   ■ 

CL2720 
CL2726 

LL 

LL 

35.  12570- 
133,9559 1 

INFINITY- 

• 

CL2730 
CL2726 

LL 

LL 

81 7.06519- 
35. 12570 

INFINITY- 

• 

CL2721 
CL?73n 

LL 
LL 

569.89365- 
87,31994 

INFINI TY- 

• 

CL2720 
CL273? 

LL 
LL 
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9.  Sample  Output  of  "Update  B-Solution"  and  "Report" 


L.P. 
Col. 
No. 

0301 
03U2 
Oou3 
U3j4 

-'"'3o'-J_. 
u  3  u  6 

03u7 
■  03uA 
03u9  ' 
U3iO 

_a3ii_ 

0  3  i  3 
031'+ 
031  b 
03i«0 
0317 

0319 
03^0_ 

"  03-:  1 
03^;d 

_03^3 
G3L;0"'" 
03ol 
0  3:^2 

"  Ooo3'" 
G3o'4 

_0  3Lit5_ 
0  3l>*'' 
0  3:^7 

_  0  3::.', 
03;>S' 
0  3wii 

_  i}3ul 
'C3u;^ 
03o3 
C3o'f 
C3i./j 
U3uo 

_  O'+ul 

r.  ii  1 .  -.t 


Sij 
SLJ 
SLi 

bn 

bB 

bn 

SB 

bL^ 
bH 
bB 
bO 

bb 

SB 
bb 

bB_ 
"bB 
bG 
bB 

bB 

SB 

bb 

bB 

bi5 

bB 

bB 

bB_ 

bb" 

bB 

SB 

^\i 

bB 

bu 


bB 
bB 
bb 
SB 


^ 


-(J 
f^   I 

d 
.  B 

B 

B 
_b_ 

B 

B 

o 

B 

b 

B_ 
B 
B 
B 

"b 

B 
B_ 
B 
B 
B 
ij 
B 
_i3 
b 
b 
b 

b 

(• 

"b" 

c  ■ 

b 
b 
b 
b 
"s" 


Description 

12    HAMS    (A    PfvICC:) 
12    HAHS    (B    PKICK) 
-I't    flAnS     (A    PRICE) 
-I't    hAXb     (B    HUICE) 
ri6_.l,l/,KiS._(A_PJaCt::)_ 
-16    HAMS     (B    PIUCE) 
-lb    HAMS     (A    PUICI-I) 

liAMb_(B 

HAMS     (A 

HAi'-iS    (i; 


-4-> 


-P 
O 


Reconimended 
Activity 


-IB 

-20 
-22 
-22 


lA, 


lb 


(B 
(A 
(B, 
(A 
(B 
^A 
(B 
(A 
(B 
(A 


-2'l    HAl-lb 
-2b    MAMS 
-26    Hai  iS 
-30    Hams 
30'"riAMb 
35    HAMS 
3b    ii/UiS 
-UP    HA'.S 
-UP    HAi!b 
-bOWU_2    CJ    HA.ViS 
3  2  'Gk    SK    ham 
"I'y    C-B    SK    HAM 
GU    SK 
0,<    SK 
G.<    SK 
G^_SK 
C\i    SK 
SK 
SK 
SK 
St\ 
SK 

Sl'v 


PBICF.) 

PKICE) 

PHICE) 

PKICE) 

"PKlCt")' 

PUICE) 

PRICE) 

PKICE)" 

PKICE) 

PKICE)_ 

PKICE) 

PKICE) 

f'KlCE) 

PRICE)" 


HAM  SKK 

HAM  FETk' 

HAI',  SKK 

HAM  FETK 


Gk 
GK 
GK 
GK 
GIv 


SKK 
FLTR 
SKK 
FLTK 


:3    o  o 
b      2 


-16 
-16" 

-IB 

-la 

-20 

-20 

-22 

-22 

-24 

-26- 

-30  ' 

-3b    Gr\    bis    HAM 

-UP    GK    S^    HAM 
25-OOWH    GR    bK    HAMS 
2!L>-UP    GK    SK    HAMS 

12  HAMS 

-l^l'liAMS 


HAM 
HAM 
H.Ai-'i 
HAM 
HAM 
HAM 
HAM 


LL 
LL 
LL 
LL 

_LL_ 
LL 
LL 
LL_ 
LL 
LL 

_UL_ 
LL 
LL 
l-k 
LL 
LL 
LI-- 
LL 
LL 
LL 
LL 
LL 
E0_ 
BS 
BS 
BS 
Cb 
LL 
BS_ 
BS 
LL 
LL 
LL 
BS 
DS_ 
3S 
LL 
LL 
LL 
LL 
l-k. 
LL 


207 


_30 
'+7 

24a 

115 
303 


_60 
59 


208 

_265 

'36 


000 


bOO_ 

255 

715 

003 

619" 

P2_l_ 
664 


451 
750 
"162' 


Reduced 
Cost 


00500- 

02000- 

00500- 

01500- 

00641- 

01641- 

00970- 

02470- 

00970- 

02470- 

00512 

0  04^8- 

00870- 

01470- 

0  0970- 

01970- 

00970- 


02470- 
00500- 
01000- 
00500- 
01000- 
01279 


01674- 
00700- 


00470- 

00470- 

01749- 

04C12- 

0  047Cr:_ 

00470- 


r-  T  K  1  ■ ,  i*»  i-» 


116 


Greatest 

• 

Least 

Cont 

Limitinf: 

• 

Coot 

"Limit 

?\.ctivit3r 

At 

Limit 

Limiting 
Activity 


At 


._»  .         ft 


• 

j>  -• 

• 

CL030r 
CL0303 
CL0405 
CL0305 

CL0777 

• 

■    ..     .   ; 

, .  -.„  ..  . 

-  ■  •  ■ 

UL                  .48000 
UL  .               .45000 
LL                  .42500 
LL     "■   ■■     .44637 

LL                  .40065 

.47500 
.44500 
.42500 
.38799 

.40000 

CL0450 

CL0451 

CL0466 

"'CL0507 

CL0354 

LL 
LL 
LL 
LL 

LL 

- 

.39500 

CL0357 

LL                  .39705 

CL0514 

CL0514 
CL0d72 
CL0458 

LL 

.37800 
,37000 

CL0411 
CL0412 

LL                  .38242 
LL                  .37800 

LL 

LL       - 
LL 

.35500 

CL0413 

LL                 .35970 
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10.  San^le  Output  of  "Report  Solution  Changes" 


b?  A   -!  LvET  WGT  H^G b  _c  UU->^0DG1  bb  \l^,tl^A'L 

Oi;[>?  J       -1  LV£  WGT  HOs'-T  2Bu-onuGi  i5     25.225 

-J    L^'£    WGT    rU'-.S    2rH-.:^rioG2    '^--^  37.>^21 


LMJ 


v'  u  - 


:\ 


il^.:  1     '\ 


H    L\' 


J'^  1    ~i 


U  w  L.  ''^ 


r-i    L7Z    .'iGl     H^JGis    30d-JPijGl     d 


H     L'v 


'T        ■! 


GT    H^r~.b    JOi)->^^HGrJ      >'^ 


oU:^^>    i;       •!    LV£    WGT    IWGb    3Uu-^2UG2    ;.b 
Oubd     K        H    LVE    WGT     H^'Gb    3Ub-J)2l.)G::,    r.-.f^ 


CuofJ 


0: 


r^    LVE     -.'Gr    ^IG;,:^    32u-3^mGl    lS 


1 1  o  t> ; '     J 


H     I.-' 


■GT    rlU.i    52iJ-o'H)G4- 


0  (J  b  7    -^ 


OUc'= 


fifl-^- 


-I    LVE    WGT    ^|i-'G.i    2ciu--'nuGa    ;^5  &l.Gi.b 


0 n ; , 'V    A       H    LV;    '^-.'GT    hlOfb    2 0^J-50uG3    dS  110.  0  5.1 

Vjn';    J       H    LVE    WGr    H^Go    2'^iU-Jnu&3    -jb  101,027 


E    ■■■JGT    'pGb    2'-i!)-300G'i      iS  l^'J.i^b'j 


:|    L\/E    WGT    H^r.i,    2aij-o0ijG(t    '^S  '■>66.5l2 


0 Qj'S    n        t    L\/E    A'GT    HOGS    2ao-50uG5    JS  106.919 

0.)bG    .>       !i    LVE    WGr    H^Gb    2rto-30uG5    -JS  2B3.129 

■  •,S         i7f-|..5;>T 


,j  n7__.\ H    LVE    WGT    H-)3a    2/^U.-.::^0'l^'A_}r' 

0  0=")''^    M       H    LVl    /JGT    HJG'i    30U~-:>20Gl    l)5 


0  (j  /  f^    »\ 


i^y;' 


k'L. 


-j    LVE    .'/GT    h^rv'^b    30u'J.^l''i-iGl     ;-b 
•  •    .'E    -'GY    r>rv'^    3 i i 1 1 [)Gi;^\G^i_f. 


_0j7£_^ 


-i    uVE    '.-.GV    P^^::.    3  JuD->'''' ■n1G2     - -•> 

■I    L *'■  £      l^-^T    7>r~'j,    jO u '")■>> '.''.iGj    ,,S 
-1    L*'E    ■•■''GY    ;'r\'--) 


'4.Gn'+ 
3.7t|!; 


5.'>35 
22.737 


H  LVE  WGT  HGGb  3UU-32jGj  -.^S     5b.3ul 


:j\]--\     ,.       -1  LVE  ^-fGT  MOGb  30u-320GLt  ,,S  25.27? 

OuL.1  _.   M  LVE  WGT  H^.^b  30u-o2CG'+  dS  &37nT9 

OGb?  A   H  LVE  WGT  HOfb  30j-o20G5  i-S  30. '^^l 

'6oL2  :)   -i  LVE  WGT  H^Gb  30o-^2uG5  JS  69.705 

LVE  A'GT  hC-GS  30u-32UGG  :jS  133.nt^5 


0063  J   H  LVE  WGT  H^Gb  30l;-32&G5  J5    386.f)G3 


1.324 


OGG'i    o       H    LVE    l-JGT    Hl^Gb    320-^4uGl    d5  1.293 

;;,,-'^    ,,        i    LuE    'YCT    f^Osb    32o-->'J-uG2    ^.5  2.76^4 


bu:>5    o       '■!    LVE    WGY    H^Gi    32u-3'+bG2    .^b  2.54-1 

U:juG    >v       H    L.VE     .^JGT    JjJGb    32u-3'mG3    .-b  U .  (U 7 

^    LVE    VJGY    hWGb    32u-3HuC3    Jb 


6.2b7 
Q.532 


,,    LVE    WGT    H^Gb    32u-3'UiGit     :.b             23.BJR 
lUE    WGT    hG';,:5    32iJ-3'+nG5      .b ^^ ♦  1  ^ "^ 


H  LVE  WGT  ^!G0:3  o2u-j'luG5  :.b     2o.4b7 

-!    :  \  ^     •:r,-^    Hw,,^    32u-3iKj-b    -b  37.72i 


ri    LVE    WGT    HGGi    32.J--:)'+0Gb     ->b  lGd.2L.>2 

•  i    i   vE    WGT    pf^-^^    30unGW\f^I     :.  b  ^l-^liL 


7  (-: .  n  0  i 

99,33\ 


7l;.a5t+ 

Ho. 71 3 
5u.394 
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07.3  i>  P_ii j-;___CL  U  U  U  'c^  U  l.  . 

36.2736^)-   CLOOOl     UL 


i.    \r  X    '  i    i  I 


INFINITY 
TNFIMITY 


m. 9481+5-  CLOOOl 

Q^b6B9'^-  C  LO  0  n  a_ 

■"5.19751-  CLOOOl 

R.gin^F)-  CL0n02 


UL 
_UL 


UL 


INFINITY 

_INFJMIJY_ 
INFINITY 

INFINITY 


3.5P.3o5-       CLOOOl  UL 

10.55011-       CL0n02  UL 

3.30300-     cITn  0  0  1 


3.1b277-       CL0n0_2_ 


UL 
UL 


1.2201'+-   CLOOOl     UL 
INFINITY-  MONE 


INFINITY 

INFINITY 

INFINITY 
INFINITY 

INFINITY 


1R4. 72678-   CLOOOl 


299.73650-   CLOOnZ 
156.21537-   CLOOOl 

4q.MQm2-  CLOon2 


UL 
UL 


IN-IMITY 
INFINITY 


UL 
UL 


16.63221-   CLOOOl 
4  4.^;"  4730-   CL0nn2 


UL 

UL 


IN^^INITY 

INFPJITY 
INFINITY 

INFINITY 


14.420bD-   CLOOOl 
37.01056-   CL0002 


UL 
UL 


INFINITY 
INFINITY 


10.31561-   CUOOOl     UL     IN-INITY 
q^5or,r)7_   CL0002     UL     INFINITY 


2.51769-   CLOOOl     UL     INFI^1ITY 

p. '+6.  "'7575-   CL00n2     UL     INFINITY 


704.26055-   CLOOOl     UL     INFINITY 
405.»31>i4-   CL0002     UL     TN^INITY 


358.61265-   CLOOOl     UL 
279.33320-   CL00n2     UL 


INFINITY 
INFINITY 


""145.4B05'3-   CLOnOi     UL     INFINITY 
117.  P.  1.^7 6-   CL0002     UL     INFINITY 


30.U1946-  CLOOni 

13B.^00fi4-  CLOOO^ 

'~3'i+7SH930-  CLC'o'n  1 

29.P92U6-  CL0002 


UL 
UL 


INFINITY 
INFINITY 


UL 
UL 


INFINITY 
IN-IVITY 


0.57631-  Cl.0001 

15.n34U'i-  CL0n02 

i I. 033^4-  CLOOOl 

1  1.46-^23-  CL0On2 


UL 
UL' 


IN-INITY 
INFINITY 


UL 
Ui- 


13.1c-3uO-   CLOOOl 
24.1^.177-   CL0  00  2 


UL 


INF  INI  lY 

TNI^rilTY 
INFINITY 

IN-INITY 


16.31220-       CLOOOl 


i"^  /\         r*.  r\  r~%  ' 


UL 


!  II 


IIFIVI  "1  Y 
INFriilY 


NON=: 

N'^N' 


NONE 

NONE 
"NONtT 

NON^ 


NONE 
NONE_ 

"sT'v^E 

NONE 


NONE 

NONE 


NONE 
N^NE 


NONE 


NONE 
NONE 


NjON" 
>.|  '^  \!  F 


"TTNE 


NONE 


^^ONE 
NONE 


NONE 
N'^NE 


N'^NE 
NONE 


NON  = 


NONE 
v)  '>  .•>j  ~ 


NON=^ 


NONE 


MO'.;: 


non: 


•I0\: 

n'^n: 
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11.      Sample  Output  of   "Monitor   Inconsistencies" 


0306  '-.tV6  3'l£+-l6    HA^lS    (B    PRICE)  I  NCQNJSiSTENT 

0'66o .  0 S       2  _?5::lUP^GR_SK_HA,.MS lNCONSlSTcNT_ 

"06bO  .0  P    14-16    SMOSKLS    .VA    FC    HM    I  ,\IC0NJ5lST£,MT 

i&l3  0.0  P    FRESH    PICNIC    CHUNKS  I.MCONjSiSTENT 

410 0 0  . I    lL-18    REG    LN I  NC ONJS I  STENT. 

3015         -99.99  INCOMSISTEMT 

iiOl?         -99.99  INCONSISTENT 

6020 -99.99 ^INCONSISTENT^ 

3050         -99.99  INCONSISTENT 

5059         -99.99  INCONSISTENT 

bOoO -99.99 INCONSlSTENT_ 

5061         -99.99  INCONSISTENT 

8065         -99.99  iNCONSiST-NT 

8121 0. ^I_20*    PK    TF:IM_(21) I  NCONSi  STENT_ 

6122               0.  1    PICNIC    TRivi     (22)  INCONSISTENT 

L140               0.                    I    H0»    LEAN    BF    (^0)  INCONSISTENT 

8142  0. I_85^_cJF    ChO    BRIS    (42)  INCONSISTENT 

"3iq.5  0.  I  80;^  lean^beef'^c+s)  inconsistent 

6152  0.        I  '70'^    LEAN  BF  (52)        INCONSISTENT 

8158      0. 1_2QX,J>K    TRlM__(b6) INCONSiSTENT_ 

'81&7  V.        I  aoA,  LEaN'BF  (67)        INCONSISTENT 

8266  -^  .tvaai    0  PiC  CHUNKS  (66)         INCONSISTENT 


0022  INCONSISTENT         NO  DESCRIPTION 


Chapter  IV 

CONCLUSIONS  AND  IMPLICATIONS  FOR  MANAGEMENT 

IV. A.   On  the  Use  of  Static  Models  as  the  Basis  of  Plans  in  Dynamic 
Environment. 

We  begin  by  stating  the  obvious :  a  static  model  suffices  as  the 
basis  for  plans  in  a  dynamic  environment  if: 

1.  It  can  be  used  in  quasi-static  fashion,  i.e. 
allowed  to  vary  with  the  world  so  that  it  accurately  reflects 
the  state  of  the  world  at  every  pertinent  instant  of  time  and 
if  this  instant's  plan  is  adequate  for  the  next  few  instants 
(the  planning  horizon) ;  or 

2,  The  plan  drawn  from  the  model  has  an  inherently  long 
life  in  the  face  of  changes  in  the  world. 

Thus,  there  are  two  distinct  parts  to  any  consideration  of  the 
viability  of  a  static  model  in  a  dynamic  environment.  We  first  must 
ask  whether  the  model  can  be  kept  up-to-date,  and,  if  so,  whether  an 
instantaneously-drawn  plan  based  on  the  present  information  set 
(which  may,  of  course,  include  forecasts)  has  applicability  for  the 
future.  The  "ideal"  system  of  Chapter  II  is  a  perfectly  feasible 
method  of  keeping  a  model  up-to-date  and  of  drawing  plans  essentially 
instantaneously.  The  real  system  of  Chapter  III  is  a  close  approxi- 
mation. We  must  assume  that  some  models  based  on  a  current  informa- 
tion set  have  relevance  for  the  future.  An  LP  model  based  on  physical 
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reality  (relatively  slow  in  changing)  must  be  relevant  for  the  future, 
except  in  the  presence  of  the  very  special  kinds  of  perturbations  dis- 
cussed in  Section  III.D. 

This  brings  us  directly  to  the  second  question:  whether  something 
in  the  nature  of  the  plan  drawn  from  the  model  gives  it  a  long  life 
in  the  face  of  changes  in  the  world.  LP  solutions  have  two  charac- 
teristics which  tend  to  give  plans  based  on  them  a  somewhat  longer 
life  than  might  be  expected  simply  on  the  basis  of  C-ranges  and  vari- 
ability of  prices: 

First,  post-optimality  information,  especially  reduced  costs  and 
C-ranges,  is  of  considerable  help  in  coping  with  many  changes  in  the 
world. 

Second,  the  payoff  from  use  of  an  LP-based  solution  may  be  so 
high  that  even  if  the  world  changes  and  we  incur  minor  non-optimalities, 
we  are  willing  to  hold  to  the  plan  as  being  better  than  another  alter- 
native. The  report  structure  of  the  "ideal"  and  real  systems  is  de- 
signed to  exploit  both  these  points. 

We  are  willing  to  conclude,  then,  that  some  static  models  are 
viable  in  some  dynamic  environments,  vriien  surrounded  by  appropriate 
supporting  structure.  We  claim  that,  for  the  case  of  LP  in  meat- 
packing, we  have  built  such  a  structure  and  made  it  work  reasonably 
well. 
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IV. 3.  LP-3ased  Planning  Systems  for  Meat-Packers  are 
Probably  Inevitable 

Everything  in  our  experience  at  Peerless  served  to  underline  the 
basic  assumption  with  which  we  undertook  the  project: 

LP  is  a  highly  useful  technique  for  planning  in  a 
fully  integrated  meat-packer;  its  potential  payoff  is 
very  high. 

The  best  evidence  we  have  for  this  comes  from  our  early  test 
runs  in  vriiich  one  month's  actual  operations  were  compared  against  one 
month's  recommendations  from  the  LP.   In  these  tests,  it  was  impossible 
to  get  an  exact  comparison  between  actual  and  LP  results,  because  the 
LP  objective  function  and  the  actual  profit  function  are  not  identical. 
However,  by  loosening  and  tightening  certain  bounds  (primarily  those 
on  allocation  of  raw  material  to  manufacturing),  we  were  able  to  approxi- 
mate the  net  change  in  expected  profit  due  to  moving  from  what  was  ac- 
tually done  toward  what  the  LP  recommended  as  about  $250,000  for  the 
month.  The  particular  month  chosen  was  thought  to  be  typical,  so  we 
are  talking  about  $3,000,000/year  or  I'jd   of  sales. 

The  second  piece  of  evidence  showing  the  value  of  LP-based  planning 
systems  comes  in  the  form  of  what  we  can  call  "revelations."  Time  after 
time,  in  checking  over  LP  output,  someone  would  find  a  level  which  seemed 
unusual  and  we  would  investigate  the  reasons  for  it.  Often  enough,  of 
course,  the  strange  level  could  be  traced  to  a  data  error,  either  in 
price  or  yield.   Sometimes  it  was  caused  by  an  error  in  model  structure. 
But  a  substantial  number  of  such  investigations  showed  the  LP  recommend- 
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ing  a  mix  of  raw  materials  for  a  particular  production  process  which 
was  indeed  a  more  economical  way  of  production  than  woula  have  occurred 
to  the  provisioners  and  product  managers. 

This  effect  was  to  be  expected.   Peerless*  production  planning 
system  before  LP  used  industrial-engineering  developed  standard  methods. 
These  were  the  best  ways  of  producing  specific  products  —  given  spe- 
cific raw  materials.  The  normal  production  scheduling  problem,  however, 
calls  for  producing  some  mix  of  final  products  from  some  mix  of  raw 
materials.  This,  the  LP  system  did  consistently  better  than  any 
human  could. 

Meat-packing  appears  to  be  a  very  competitive  business  (in  the 
economic  sense).   Margins  are  generally  low.   If  any  packer  were  to 
suddenly  come  upon  a  technological  innovation  increasing  his  yields  by 
15S  across-the-board,  he  would  eventually  force  other  packers  to  adopt 
the  same  innovation.   The  same  can  be  said  about  LP-based  planning 
systems,  so  we  believe  that  such  are  inevitable  in  the  meat-packing 
industry,  particularly  for  large,  fully-integrated  packers  like 
Peerless. 

Moreover,  it  is  possible,  under  certain  circumstances,  to  make 
such  a  planning  system  viable  even  without  large  internal  data-process- 
ing capability.  This  point  is  discussed  in  the  following  sections. 
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IV. C  Large  Internal  Data-Processing  Capability  Is  Not  Strictly 
Necessary 

While  the  ideal  system  of  Chapter  II  would  have  been  desirable, 
the  real  system  of  Chapter  III  was  extremely  powerful.  It  had  vir- 
tually all  the  global-periodic  capability  of  the  ideal  system  and, 
through  human  agents,  some  of  the  real-time  capability.   Its  basic 
cycle,  exclusive  of  data-collection,  was  still  dropping  at  the  end  of 
the  project,  but  can  be  estimated  at  about  12  hours,  with  8  a  lower 
bound  and  24  an  upper  bound. 

This  was  achieved  with  severely  limited  internal  data-processing 
capability.  Perhaps  the  most  serious  restriction  was  the  lack  of 
random-access  storage  devices.  Besides  somewhat  complicating  all  pro- 
cessing, this  led  to  the  necessity  for  much  more  paper  than  would 
otherwise  have  been  required,  since  machine  look-ups  were  out  of  the 
question. 

Moreover,  a  system  of  this  sort  is  possible  only  in  the  presence 
of  a  service  bureau  or  similar  facility  in  iirtiich  one  has  some  confi- 
dence. We  were  extremely  fortunate  to  have  the  cooperation  of 
Nonpareil,  UNIVAC,  and  IBM  in  this  effort. 

One  possible  complication  stemming  from  insufficient  internal 
data-processing  capability  is  discussed  in  the  next  section. 
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IV. p.   Some  Change  in  Internal  Human  Resources  is  Necessary 

The  most  troublesome  by-product  of  limited  data-processing  capa- 
bility is  the  limited  amount  of  human  data-processing  expertise.  In 
general,  the  smaller  one's  EDP  installation,  the  fewer  people  are  re- 
quired to  support  it,  and  the  less  sophisticated  they  are. 

At  Peerless  we  found  people  of  a  generally  good  level  of  com- 
petence spread  very  thin  over  the  range  of  existing  and  new  EDP  appli- 
cations.  As  a  result,  much  of  the  programming  for  the  system  as  in- 
stalled was  done  by  programmers  supplied  by  UNIVAC.  While  they  did 
an  excellent  job,  they  were  not  able  to  completely  turn  the  system  over 
to  Peerless'  own  personnel.  More  than  once  we  had  to  call  on  UNIVAC 
to  debug  a  program  long-since  checked  out  and  put  into  operation. 

At  the  same  time  we  found  very  few  people  outside  the  EDP  group 
itself  who  understood  the  capabilities  and  limitations  of  an  EDP- 
based  LP  system  in  even  the  most  general  terms.   More  will  be  said 
about  this  point  in  following  sections,  but  here  we  simply  assert  that, 
while  installation  of  an  LP-based  planning  system  does  not  strictly 
require  a  large  in-house  EDP  operation,  it  does  require  such  human 
resources  as  are  likely  to  be  found  only  in  a  firm  with  large  EDP  op- 
erations. If  these  people  are  not  already  present,  they  have  to  be 
hired  and/or  trained. 
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IV. S.   '.^fhy  the  System  Was  Not  Used  at  Peerless 

This  section  explores  sorne  of  the  reasons  why  the  system  was  not 
used  at  Peerless.   In  most  cases  the  reasons  are  generalizable  to  other 
situations,  so  they  belong  here  among  the  management  implications  of 
this  work.   This  section  is  based  on  two  premises,  neither  of  which  is 
necessarily  true: 

First,  we  assume,  on  the  basis  of  the  evidence  presented  so  far, 
that  the  system  should  have  succeeded.   That  is,  we  assume  that  the 
pay-off  from  the  system  would  have  more  than  paid  its  cost,  and  that 
it  could  have  been  used  successfully  at  Peerless.   It  has  been  suggested 
that  because  of  cash  constraints.  Peerless'  strategies  were  so  circum- 
scribed as  to  make  the  LP  system  useless.  We  do  not  believe  it.   In 
fact,  most  of  the  power  of  the  LP  system  comes  from  its  ability  to 
allocate  scarce  resources,  and  cash  can  be  (though  it  was  not)  treated 
like  any  other  scarce  resource. 

Second,  we  assume  that  the  system  will  not  be  used.   As  of  this 
writing,  it  is  planned  to  re-open  the  question  of  the  LP  system  in  six 
months.  We  expect  nothing  to  come  of  this.   Start-up  costs  are  too  high, 
especially  since  key  personnel  have  left  Peerless  in  the  interim. 

So  we  now  ask  what  general  principles,  if  any,  were  violated  by 
this  project.   On  investigation,  we  find  several. 

A  Planning  System  Should  be  Initiated  by  Its  Ultimate  Users  with 
the  Approval  of  Their  Superiors :   This  system  was  initiated  by  the  chief 
executive  officer  of  Peerless.   It  was  at  no  time  a  project  of  its  ul- 
timate users,  the  provisioners.   This  is  not  to  say  that  the  provisioners 
opposed,  actively  or  passively,  the  construction  or  use  of  the  system. 
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To  the  contrary,  they  were  generous  of  their  help  in  development, 
testing,  and  initial  implementation.   But  it  was  not  their  idea  nor 
was  it  their  system. 

The  Model-Building  Exercise  is  Valuable  Only  to  Those  Who 
Participate:   The  model-building  activity  (described  in  Section  III.E.) 
was,  as  expected,  valuable  to  Peerless.  The  group  which  most  directly 
benefitted  was  Process  Design.   By  the  time  the  whole  model  had  been 
placed  in  operation,  Process  Design  had  an  excellent  overview  of 
Cedarton  operations  and  a  real  understanding  of  the  interactions 
present.   The  provisioners,  however,  did  not  participate  directly  in 
model-building,  and,  as  a  result,  did  not  share  the  "world-view"  en- 
joyed by  Process  Design. 

It  is  of  no  importance  whose  understanding  was  "better"  or  "closer 
to  the  truth,"  of  course  —  the  important  fact  is  that  the  provisioners 
did  not  recognize  the  model  as  theirs.  The  result  was  that  an  important 
side  effect  of  model-building  —  increased  understanding  of  the  process 
modeled  —  was  not  directed  to  the  group  which  could  most  profit  from 
it. 

A  Planning  System  should  be  Designed.  Constructed,  and  Maintained 
by  Its  Ultimate  Users:   The  Peerless  system  was  designed  largely  by 
outside  people,  constructed  largely  by  outside  people,  and  maintained 
by  people  with  no  connection  with  the  provisioning  function.   Outsiders 
supplied  the  designers;  the  model  was  constructed  by  outsiders  and 
Process  Design;  the  programs  were  constructed  by  outsiders,  UNIVAC, 
and  EDP.   The  provisioners  were  not  involved  except  as  data  sources 
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and  prospective  users.  The  closest  thing  to  the  provisioners'  taking 
control  came  vrtien  a  recent  MBA  was  hired  by  provisioning  to  serve  as, 
among  other  things,  the  interpreter  of  the  LP.  This  was  definitely  a 
step  in  the  right  direction,  but  the  problem  was  that  this  man's  time 
was  so  absorbed  by  the  LP  system  that  he  never  properly  became  part 
of  provisioning. 

A  System  Needs  a  Home:  Responsibility  for  maintenance,  operation, 
and  interpretation  fell  on  three  separate  men.   Only  one,  mentioned 
above,  was  remotely  connected  with  provisioning.  Moreover,  these  three 
reported  to  three  different  supervisors  on  different  levels.  No  single 
man  below  the  chief  executive  officer  had  effective  control  over  the 
system.   Overall  responsibility  should  have  rested  with  the  chief  pro- 
visioner  since  it  was,  in  fact,  built  for  his  use.   He  never  took 
charge  of  it,  though  he  was  most  helpful  in  its  development  and  testing. 

Timing  is  Critical:  Although  the  project  competed  with  PYRAMIDS 
for  programming  time  and  management  attention,  it  was  in  pilot  opera- 
tion long  before  PYRAMIDS.  As  a  result,  no  advantage  could  be  taken 
of  the  PYRAMIDS  data  collection  subsystems.  Data  had  to  be  collected 
manually  for  each  LP  run.   This  imposed  a  nearly  intolerable  burden  on 
the  data  sources  (Product  Managers  and  Process  Design),   Attempts  at 
full  operation  came  at  a  time  when  Peerless  was  short  of  cash  and  did 
not  feel  able  to  plan  at  all.   It  might  well  have  been  better  to  defer 
these  attempts  until  after  PYRAMIDS  came  into  operation  and  to  a  less 
cash-bound  period.   In  retrospect,  this  would  have  meant  waiting  about 
four  months,  but  this  could  not  have  been  anticipated. 
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IV. F.   The  Next  Logical  Step:   Pricing 

In  Section  II. B.  we  described  Peerless  as  a  price-taker.   Never- 
theless, the  LP  model  described  in  Chapter  III  recognized  that,  in  the 
case  of  purchase  of  primals.  Peerless  is  large  enough  to  affect  the 
market  price.   To  account  for  this  effect,  piece-wise  linear  price 
functions  were  introduced  for  purchased  hams  and  bellies.   However, 
the  current  model  takes  no  account  of  price  effects  for  sale  of  either 
primals  or  finished  products. 

Because  the  current  form  of  the  model  does  take  explicit  account 
of  finished  products,  it  already  gives  the  marketing  and  sales  functions 
some  help.  Marginal  Return  figures  guide  the  marketing  managers  in 
whether  or  not  to  give  price  concessions  to  obtain  volume,  for  example. 

But  the  present  form  of  the  model  recommends  quanitites  given  es- 
timated prices.   It  would  be  desirable  to  extend  the  model  to  recommend 
both  quantity  and  price  for  many  major  finished  products.   Assuming 
that  demand  curves  can  be  determined  and  that  they  are  convex,  there 
are  two  approaches  available  to  us,  piece-wise-linear  pricing  and 
quadratic  pricing. 

The  piece-wise-linear  approach  has  the  virtue  that,  since  it  is 
already  used  on  the  purchase  side,  it  is  likely  to  be  understood.   It 
also  requires  no  major  changes  to  the  LP  support  system.   Its  major  dis- 
advantage is  that  it  yields  not  a  single  price,  but  a  set  of  prices 
and  corresponding  quantities.   Interpretation  of  these  as  a  single 
price  has  pitfalls  unless  a  true  multi-level  marKet  exists.  Another 
problem  of  piece-wise-linear  pricing  is  that  the  whole  set  of  prices 
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and  bounds  has  to  be  part  of  the  model  run  each  time.  This  increases 
the  volume  of  data  needed  before  each  run  and  the  length  of  time  re- 
quired for  each  run. 

The  quadratic  pricing  approach  does  not  share  the  disadvantages 
of  piece-wise-linear  pricing.  It  yields  a  single  unambiguous  price 
and  corresponding  quantity.  Moreover,  many  quantities  will  be  con- 
trolled by  marginal  return  considerations  rather  than  explicit  bounds. 
These  quantities  will  be  generally  expressible  as  linear  functions  of 
prices,  initial  inventories,  and  so  on,  so  that  a  plan  based  on 
quadratic  pricing  can  be  expected  to  experience  less  solution  decay 
than  a  pure  LP  solution.  The  catch  is  that  the  parameters  of  the 
quadratic  demand  curves  have  to  be  determined  initially  and  updated 
to  reflect  major  market  changes.   This  requires  a  level  of  understand- 
ing and  research  which  Peerless  does  not  have  and,  in  fact,  it  is 
quite  possible  that  demand  curve  determination  simply  cannot  be  per- 
formed well  enough  to  justify  the  effort. 

Quadratic  pricing  would  also  require  access  to  a  good  quadratic 
programming  computer  code  and  major  changes  in  the  LP  support  system. 

In  spite  of  its  complexity,  the  extension  of  the  planning  sys- 
tem into  the  area  of  pricing  would  give  the  entire  procurement/pro- 
visioning/production/marketing/sales complex  a  single,  consistent, 
global,  economic  plan  from  which  to  work.  The  potential  payoff  from 
the  large  effort  required  to  achieve  this  is  enormous. 
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Appendix 

This  appendix  contains  a  listing  of  an  early  version  of  the 
reduced  model  originally  tested  in  Cambridge.   The  model  is  in  1620 
LP  format  and  still  contains  a  few  inequalities  with  corresponding 
non-zero  right-hand-side  elements. 
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